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