Hello Karl, Don't you think stored properties in extensions would encourage the kind of code you talked about. I believe may you're doing it while understanding it's implications and also accepting the fact that it's not easy to write UI code in a modular way, but do we want everyone to think like this? Should we accept defeat on the face of this problem that there's no way to write UI code in a modular way where we don't have to put everything in one massive view controller?
I feel we would be just raising our hands up if we do it this way On 24 March 2017 at 16:49, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > 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> 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> 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 > 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 > > -- *Pranshu Goyal* *iOS Developer* *tlkn*
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution