[swift-users] Class vs Structures

[Vitor Navarro]

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 <kelvin13ma at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170630/8728ea2d/attachment.html>