> On 24 Mar 2017, at 12:13, Vladimir.S <sva...@gmail.com> wrote:
>> On 24.03.2017 12:50, Haravikk wrote:
>> I can see why some people might want to do stored properties in extensions
>> to structure things, but personally I quite like the lack of flexibility as
>> it encourages the initial type declaration to focus on what a type
>> *contains*, while extensions focus on what it *does*. I've really taken to
>> that style, as I now almost never declare methods or computed properties in
>> an initial type declaration, unless it's a very simple one; instead doing
>> all my methods and protocol conformances in their own extensions.
>
> The main problem I currently see with extensions: you can't conform to
> protocol in extension if you want to have stored properties to implement the
> protocol. And conforming to separate protocol in separate extension is a
> common practice and usually you need this in the same file when you define
> the type.
> *This* was my main point when I suggest to allow stored properties *only in
> the same file where the type is declared*.
Even, so I think this is kind of the right way to do it; protocols don't
specify stored properties, only a name and type, so IMO it doesn't necessarily
follow that fulfilling that requirement with a store property belongs in an
extension.
Consider for example a conformance to Indexable, I want to do this in an
extension and I need to decide to how I'm going to handle the startIndex and
endIndex properties. For some reason I decide I'll store one in my type and
compute the other:
struct MyCollection<E> {
let startIndex:Int = 0
}
extension MyCollection : Indexable {
var lastIndex:Int { return someValue() } // it's a really bad
collection
}
Bit contrived I know, but here I've been forced to think about where to put
each, hopefully making it more obvious that my choice for startIndex was a
waste of space, since it has made MyCollection 4/8 bytes larger.
I just really like that property of the pattern; it also means that, if I keep
the type declaration clean, then at a glance I can see what contributes to the
type's actual contents and size. Here someone new to the code would immediately
see that I was an idiot 😉
I'll agree that there's some separation from the protocol that it was actually
required by, but I prefer it that way to having stored properties scattered
around, even within the same file (especially since we're often talking about
very large files here for complex types). This "feature" is good for someone
new to the code as it makes it easy to learn what is a stored vs computed
property, especially if it has encouraged the developer to keep the number of
stored properties to a minimum.
I dunno, maybe it comes from having once had header files for everything, but I
like this separation of concrete components of a type.
There was a proposal a while ago as an alternative to stored properties in
regular extensions, which was the use of "mix-ins", which would be its own
category. The aim of those is to modularly build up a type and quickly add
conformances from reusable mix-ins, but you could also do it just for a single
type.
I preferred that idea because it formalises that this is something you can't
just do to an imported type, and gets away from this idea of having something
you can do with an extension, but only at the file-scope, which I feel kind of
weird about._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
