<div dir="ltr"><p class="MsoNormal">I would agree with you that protocols in swift are
equivalent to interfaces in other languages.
However exactly equivalent may not be totally correct. How interfaces are used in an OSGi bundles for
dependencies with Java is different than how we use protocols in Swift. You are correct that the underlying philosophy
between interfaces and protocols are equivalent, how they are used in the
various languages and programming paradigm can be significantly different.</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">Where I respectfully disagree with your statement is when
you say that protocol extensions are exactly equivalent to global functions
that take an object of the protocol type as a parameter. The most obvious difference is global
functions reside in the global scope while protocol extensions are part of the type
instance. We can override functionality provided
from a protocol extension if we need specific functionality for a particular
type. We can also use constraints with protocol
extensions to limit the types that will receive the functionality from an extensions. There is just so many ways that make protocol
extensions superior to global functions that even if you do not agree with the
Protocol Oriented programming paradigm, I would recommend taking another look at
protocol extensions.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Jon</p></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 7:36 AM, Daniel Tartaglia <span dir="ltr"><<a href="mailto:danielt1263@gmail.com" target="_blank">danielt1263@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Jon,<div><br></div><div>Here’s the thing… Swift protocols are exactly equivalent to OO interfaces. Swift protocol extensions are exactly equivalent to global functions that take an object of the protocol type as a parameter.</div><div><br></div><div>The only difference is in some syntactic sugar. </div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Feb 15, 2016, at 8:13 PM, Jon Hoffman <<a href="mailto:hoffman.jon@gmail.com" target="_blank">hoffman.jon@gmail.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">
<p class="MsoNormal">Please excuse my ignorance on ECS. I did read though the link that you sent and
also a few other sites on ECS namely <a href="https://en.wikipedia.org/wiki/Entity_component_system" target="_blank">https://en.wikipedia.org/wiki/Entity_component_system</a> and <a href="http://www.gamedev.net/page/resources/_/technical/game-programming/understanding-component-entity-systems-r3013" target="_blank">http://www.gamedev.net/page/resources/_/technical/game-programming/understanding-component-entity-systems-r3013</a>. It does appear that ECS design is a lot
closer to POP then OOP based on what I read however I may not fully understand
ECS.</p><p class="MsoNormal">Lets take a couple of land animals as examples. If we had a Lion, it would attack either
using it’s claws or it’s teeth. An
Alligator would use it’s teeth on land. A
snake or spider would inject venom into it’s victim while some snakes may also
squeeze the victim to death. With ECS, I
believe we would have components for each type of attack. Is that correct? Then we would add the component that we need
to our entity (animal). </p><p class="MsoNormal">If my description is correct, then I believe this is very
similar to a POP design where we would use protocols to define the component
and protocol extensions to add the functionality. This would mean we would have the BiteAttack,
ClawAttack, VenomAttack and SqeezeAttack protocols with protocol extensions to
add the functionality. Do I understand
ECS correctly? This type of design is
very good where we break all of the components down into individual types.</p><p class="MsoNormal">One advantage to using POP to implement ECS is we would
define the requirements when we define the animal type. What I mean by that is we would specify what
protocols the type conforms to when we define the type. This
prevents developers from adding the wrong components within the code. The draw back with using POP would be the
type definition could get pretty long because we would need to list all of the
protocols that a type needs to conform to.</p><p class="MsoNormal">One point you made, if I understood you correctly, is that
with POP we would have larger types as compared to ECS however if we use
protocol extensions to add the functionality to our component types, I do not
believe our individual animals types would be much bigger than the ECS
ones. </p><p class="MsoNormal">Do I understand the ECS design correctly?<u></u><u></u></p>
<div>Jon</div><div><br><blockquote type="cite"><div>On Feb 15, 2016, at 5:51 PM, Adam Eberbach <<a href="mailto:aeberbach@me.com" target="_blank">aeberbach@me.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">For a third approach take a look at <a href="http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/" target="_blank">http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/</a> and the following posts (5). <div>Entity Component Systems avoid the problem of everything migrating up into the base class and the propagation of classes by separating aspects (attributes, things the entity has) of the entity into components. The entity itself is little more than a UUID handle to the components owned by that entity. In this example an alligator has a LandComponent and a SeaComponent. A System contains the code that acts on the data contained in those components and there is a system for each kind of component, for example a LandSystem that has code to make an entity move on land. Each update the System acts on every entity that has a component matching it. </div><div><br></div><div>The description above is the more modern AAA-game ideal of ECS but there is disagreement about the fine points (of course!). Apple’s GameplayKit implements an older form of ECS like that developed by Scott Bilas for Dungeon Siege (<a href="http://scottbilas.com/games/dungeon-siege/" target="_blank">http://scottbilas.com/games/dungeon-siege/</a>) in 2003, where components have code and data. </div><div><br></div><div>I think this is very like the POP idea… but perhaps cleaner since the System processes, subject to the usual sync issues, can be separate threads. Adding a behaviour or a new entity is as simple as choosing the right components, aggregating them into an entity and then adding that entity to the update loop. And it doesn’t matter how many aspects you add to a class - all the code is encapsulated in the System, all the data in the Component. The POP approach is pretty good but you still wind up with a very beefy class.</div><div><br></div><div><div><blockquote type="cite"><div>On 16 Feb 2016, at 6:21 AM, Jon Hoffman via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br><div><div dir="ltr"><p class="MsoNormal">Sorry for the misunderstanding, I see what you are doing now,
you are using the command pattern, however I so see quite a bit of difference
between your design and my POP design.<span>
</span>The biggest is the number of types needed between the designs.<span> </span>For example, how the Lion attacks and moves on
land is different than how the Alligator attacks and moves on land therefore
you will need separate attack and movement types for each type of animal.<span> </span>This means that you will need a Alligator
type and to go with that Alligator type you would need AlligatorLandAttack,
AlligatorSeaAttack, AlligatorLandMove and AlligatorSeaMove types.<span> </span>You would also need the Lion type with a
LionLandAttack and LionLandMove type.<span>
</span>You would need these separate types for each animal you create.<span> </span>With my POP all of this logic would be
encapsulated in a single types.</p><div> <br></div><p class="MsoNormal">By encapsulating all of the logic into a single type your
code will be easier to manage and also less error prone.<span> </span>For example, in your code there is nothing
preventing a developer to accidentally adding the LionLandAttack type to the
Alligator type and since that error could occur anyplace where an instance of
the Alligator is created it could also be hard to track down.</p><div> <br></div><p class="MsoNormal">One of the principles of Protocol-Oriented programming is
making our code safer and easier to manage.<span>
</span>Your code would work but I would still say that the POP code would be
much easier to manage long term and would also be less error prone.<span> </span>That is my opinion and everyone will have
their own.</p>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:52 PM, Daniel Tartaglia <span dir="ltr"><<a href="mailto:danielt1263@gmail.com" target="_blank">danielt1263@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">That’s easy to do by allowing an Animal to hold multiple modes. Yes, the code below uses a Protocol, but only as an OO interface.<div><br></div><div><font face="Monaco">let alligator = Animal()</font></div><div><font face="Monaco">alligator.mode.append(Land())</font></div><div><font face="Monaco">alligator.mode.append(Sea())</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">protocol Mode {</font></div><div><font face="Monaco"> func attack() -> Bool</font></div><div><font face="Monaco"> func move() -> Bool</font></div><div><font face="Monaco">}</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">class Animal {</font></div><div><font face="Monaco"> var modes: [Mode]</font></div><div><font face="Monaco"> func attack() -> Bool {</font></div><div><font face="Monaco"> for mode in modes {</font></div><div><font face="Monaco"> if mode.attack() {</font></div><div><font face="Monaco"> break</font></div><span><div><font face="Monaco"> }</font></div><div><font face="Monaco"> }</font></div><div><font face="Monaco"> }</font></div><div><font face="Monaco">}</font></div><div><br></div><div><br><div><br><div><blockquote type="cite"><div>On Feb 15, 2016, at 1:43 PM, Jon Hoffman <<a href="mailto:hoffman.jon@gmail.com" target="_blank">hoffman.jon@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Thank you for the feedback however you cannot design the code as you describe, if I understand your explanation correctly, because one of the requirements is the animals may be apart of multiple categories. As the example in the post shows the alligator belongs to both the Land and the Sea categories. In you description that would mean that the Alligator type would need to be a subclass of both the Land and Sea superclasses which is not permitted. Remember that one of the drawbacks with OOP is a subclass can only inherit from one superclass.<div><br></div><div>Jon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:17 PM, Daniel Tartaglia <span dir="ltr"><<a href="mailto:danielt1263@gmail.com" target="_blank">danielt1263@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>(Reposting because I forgot to change the subject line. Hope that this is the correct thing to do.)</div><div><br></div>I have to say John that I am not a fan of your OOP code. I would have written the OOP code very much like you wrote the POP version using the Strategy pattern.<br><div><div style="word-wrap:break-word"><div><br></div><div><div><font face="Monaco">[Animal]<*>--->[Mode]</font></div><div><font face="Monaco"> ^</font></div><div><font face="Monaco"> |</font></div><div><font face="Monaco"> +------+------+</font></div><div><font face="Monaco"> | | |</font></div><div><font face="Monaco"> [Land] [Sea] [Air]</font></div><div> </div></div><div><br></div><div>(View the above with a mono-spaced font.)</div><div><br></div><div>In essence, I see no difference. There may be a difference, but I don’t think your example presents one.</div><div><br></div></div></div></div></blockquote></div></div></div></blockquote></div><br></div></div></span></div></blockquote></div><br></div>
_______________________________________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>