> Using extensions for "code organization" is another word for writing > spaghetti code.
Using extensions for code organization is a practice established and recommended by the Core Team from the very beginning (such as this blog post from August 2014: https://developer.apple.com/swift/blog/?id=8). Additionally, here's Chris Lattner himself in regards to extensions: > This design is true to the existing design of Swift: we want to encourage the > implementation of types to be freely broken into extensions. This alignment > with extension oriented programming was the one important virtue of the Swift > 1/2 access control design that Swift 3 lost. So while you personally may not use extensions, calling the use of them "spaghetti code" is rather misguided IMO. Regardless, as a final plea to the Core Team regarding this proposal: unsurprisingly, the people who are on this mailing list represent a specific subset of Swift users, and not the Swift user base as a whole. The arguments against this proposal I truly believe are not relevant to the "average" Swift user. A newcomer to Swift would probably begin by putting all logic for a class in one class declaration, and using "private" for private members (as is expected). However, once they find out about the Swift practice of using extensions to separate out logic, they will hit a roadblock as they will be unable to use private members as is, and rather than understand why, they very well may simply choose to never adopt an extension-based workflow, which is unfortunate. However, if this proposal was accepted, they could easily go from one class declaration to one with extensions, without even having to learn about fileprivate. I truly believe this lessening of restrictions over private member in extensions (which is used by practically all levels of Swift programmers) is more important to the language than the ability to truly restrict types to just the original class scope (which I believe is primarily used by more "advanced" users). Experienced users know what they're doing, and can deal with shortcomings (such as prefixing truly private members with underscores). Newcomers/"average" users don't as much, and this friction is a much bigger deal for them. Also, while some have mentioned that this adds complexity to the access control system because types are now a factor, to that I say: this is purely a theoretical issue. In practice, developers don't care that this is case, and just care that the access control logic makes sense when using it. As someone who's had to explain why fileprivate is necessary many times to new Swift developers when using extensions, I can assure you that using this proposed private definition makes more intuitive sense to them. To sum up, please don't lessen the experience of the average Swift programmer simply because there are some gains for the more "advanced" developers; obviously not everyone can be happy, but I believe in this case this proposal will satisfy the vast vast majority of Swift programmers (aka, people not on this mailing list). Riley Testut > On Apr 16, 2017, at 1:02 PM, Rudolf Adamkovic via swift-evolution > <swift-evolution@swift.org> wrote: > > -1 from me. > > Using extensions for "code organization" is another word for writing > spaghetti code. > > It results in types with many responsibilities. In such cases, it's time to > extract collaborator types. > > But it sure looks prettier. > > R+ > > Sent from my iPhone > >>> On 7 Apr 2017, at 10:56, Jonathan Hull via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> What is your evaluation of the proposal? >> >> Strong -1. Just rename ‘fileprivate’ to be less annoying. >> >> This proposal will make things even worse than they are currently. We will >> regret it just as much, if not more than, 0025. As others have mentioned, >> it is actively harmful: >> • It once again changes the meaning of private >> • It takes away most of the actual power of private (vs fileprivate). (I was >> for returning to the simpler Swift 2 access, but when I did use private, I >> used it to limit access to just a few lines of code. This proposal gets rid >> of the last ounce of usefulness of ‘private’ for me, and only has the virtue >> of a less annoying name). >> • It is the camel’s nose in the tent for type-based access (people will ask >> for future versions to be available in the type in the submodule, module, >> and then public… but we will be unable to give it to them) >> • It breaks the same code that 0159 would have broken >> • It will be a nightmare to teach/learn >> >> Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. >> Fileprivate is the best access levels for a lot of cases, it just has an >> annoying name. Given our constraints, I now believe the only sane choice >> left to us is to make fileprivate easier to use (as opposed to making >> private more like it) and to get rid of the cognitive dissonance of having >> similar names/concepts by renaming ‘fileprivate’ to something like ‘local’. >> ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ >> should be the one being used explicitly. >> >> We are likely going to have to rename ‘fileprivate’ anyway to work with >> submodules (that or add another access level), and ‘local’ has connotations >> of visible nearby… so I think it works well enough. >> >>> Is the problem being addressed significant enough to warrant a change to >>> Swift? >> Yes, access controls are a mess… but this will make them more of a mess. >> >>> Does this proposal fit well with the feel and direction of Swift? >> No. >> >>> If you have used other languages or libraries with a similar feature, how >>> do you feel that this proposal compares to those? >> No. I have used languages with type-based private, and I have used languages >> with file-based private… but never type-based that was limited to a file. >> You got shrimp in my chocolate (not all great tastes go well together). >> >>> How much effort did you put into your review? A glance, a quick reading, or >>> an in-depth study? >> I have followed the discussion closely and spent a great deal of time >> thinking about it. >> >> Thanks, >> Jon >> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
