On 24.03.2017 14:09, Pranshu Goyal wrote:
I agree with Haravikk, enabling stored properties in extension will lead to abuse of the feature, and people will start putting any and everything while modeling classes retroactively, rather than think about the real meaning and purpose of extensions which is to provide extended functionality or convenience methods on objects without change in its basic structure.
I believe current consensus is that stored properties (at least for now) should be allowed in extensions in the same file with type declaration (probably in submodule also, when we'll have them), not across the module.
If someone wishes to really make an object which has added properties they should look into subclassing rather than extending.
Also I believe that in most cases we discuss the problem of class *declaration* in the same file, where you often want to use extensions to separate protocol conformances and to separate different kind of type's logic.
To Charles Srstka: would you start new pitch about the proposal for allowing stored properties in extensions in same file? I.e. such proposal IMO has chances to be supported and will solve the main problem you are trying to solve in current proposal.
IMO It is obvious that current proposal "as it is" will not be supported.
On 24 March 2017 at 15:20, Haravikk via swift-evolution <[email protected] <mailto:[email protected]>> wrote:On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution> -- /Pranshu Goyal/ /iOS Developer/ /tlkn/
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
