Hi Taylor,
Thank you for the answer quite enlightening and also a better explanation
than the short direction given by the docs. Could you please provide a
sample for scoping with enums? I couldn't visualize it.
Thanks again.
2017-06-29 14:41 GMT-04:00 Taylor Swift <kelvin1...@gmail.com>:
> When in doubt, go with a struct. Probably nineteen types out of twenty I
> write are structs. Swift really is optimized with the assumption that
> you’re working with structs, that’s why almost everything in the standard
> library is a value type. Structs always pack contiguously into arrays,
> while arrays of classes can get bridged to a non-contiguous NSArray. Code
> that uses classes tends to be hard to read since `let` and `var` cease to
> convey useful information about mutability. Classes also open up cans of
> worms with strong and weak ownership cycles and all that crap which is
> almost completely avoidable if you know how to use value types well.
>
> The only reason to use a class is if you really, really need reference
> semantics — i.e., the instance does not have a clearly defined owner, and
> you want any changes to the instance to be reflected in all of its owners.
> This is rare though, and more often than not this is a code smell that
> something is wrong with the larger design. Another case is when the
> instance manages some kind of external resource, like a memory buffer, and
> you have no other way of untangling the resource management from the life
> cycle of the instance. This is why Swift array buffers are classes (though
> the Array type itself is a struct which contains the buffer class).
>
> Another case where a class *might* be appropriate is when your type
> contains many many stored properties, that pushing and popping them off the
> call stack by value would be slower than pushing a reference. That’s
> usually a sign that you’re not making enough use of static or computed
> properties though. The pass by value cost is also not as important as you
> might think — small functions will get inlined by the compiler, while large
> functions don’t care since the function call cost will be dwarfed by the
> cost of executing the actual function body.
>
> Inheritance and polymorphism are *not* a good enough reason to use
> classes; that’s what extensions and protocols are for.
>
> Don’t use a struct as a scoping container; use an enum for that. Some
> people scope things to structs because they don’t remember that enums can
> be used as a namespace, but the swift idiom is to use an enum for this, not
> a struct.
>
> tldr; structs and enums are the preferred native Swift object, classes are
> really only there for programmers coming from other languages who are used
> to thinking in terms of reference types.
>
> On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi,
>>
>> I know this question is probably done a thousand times, but I wanted to
>> hear from Swift dev community.
>>
>> I think both of them have right places for usage depending on the
>> occasion but documentation, WWDC and the internet give opposite answers
>> regarding this.
>>
>> Do you guys have any guideline regarding usage here?
>>
>> Thank you.
>>
>> Vitor Navarro
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
