> On 24 Mar 2017, at 10:50, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>>
>> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>>>
>>>> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> MOTIVATION:
>>>>
>>>> In current Swift, a pattern has emerged among some developers, in
>>>> order to logically group parts of a class or struct’s declaration,
>>>> particularly around protocols:
>> >> ...
>>>>
>>>> What do you think?
>>>
>>> If we wanted to allow code like this to be written we wouldn’t need a
>>> new keyword to do it. You are proposing two things here:
>>>
>>> 1) Allow stored properties in same-module extensions. This has been
>>> discussed in the past and is a possibility, but I suspect it is not in
>>> scope for consideration during Swift 4.
>>
>> Are we really expect to have stored properties in same-module extensions?
>> As I remember, there a lot of questions were raised during discussions so
>> for some reason *I* had a feeling that we should not expect this happens in
>> near feature. Probably I missed something.
>
> 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.
>
> i.e- I quite like that by the time you've finished your type declaration you
> have finalised what its size will be, and nothing else can change that,
> spreading it out feels like it could make that more confusing. It also IMO
> helps to encourage you to keep a type's contents fairly simple, as you can
> see in one place if you've made it very complicated.
>
> I suppose there's an argument for having the freedom to do it however you
> want, but I don't think spreading out across a module is a good idea; unless
> we're assuming that module in this context applies like in other proposals,
> where fileprivate is a "module" with only one file.
>
> I dunno, I just think that as a pattern the current requirement to keep
> stored properties within a type declaration enforces some good practices. I
> found it a bit jarring at first too, but after adapting to the type +
> extensions style I find I actually really like doing things that way.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
If you have a complex class (especially in UI code), you sometimes don’t really
care about the size of the class and would prefer data to be grouped in broader
functional groups. For example, I might like my toolbar-related iVars to be in
one extension, and my datasource-related iVars in another, maybe with a couple
of protocol conformances with require the odd state variable.
Requiring all of the stored properties live in the initial declaration means
that the code is ultimately less clear: instead of being locally-declared (and
perhaps even privately-scoped), the variable is now thousands of lines away
from the only place I want to access it directly and visible throughout my
implementation for me to one day muck up its state.
Allowing stored extensions within the same file seems like a good compromise to
me, especially if its “trivial” to implement ;) Perhaps we could require such
types to have some special annotation or magic “ExtensionVariables” item, for
the benefit of readability? Just trying to find what you’d feel would be
acceptable.
- Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
