Regards (From mobile) > On Jul 10, 2016, at 7:34 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Sent from my iPad > >> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz <tseit...@icloud.com> wrote: >> >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson <matt...@anandabits.com>: >>> >>> >>> >>> Sent from my iPad >>> >>>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz <tseit...@icloud.com> wrote: >>>> >>>> >>>> >>>>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson <matt...@anandabits.com>: >>>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz <tseit...@icloud.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>>>>>> <swift-evolution@swift.org>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution >>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>> >>>>>>>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution >>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>>> I disagree that a stable for over 30 years of every OOP language that >>>>>>>>> I know is equivalent to lack of care for good library design, but if >>>>>>>>> we want to push value types by making working with classes harder so >>>>>>>>> be it :P. >>>>>>>> >>>>>>>> Making classes harder to work with is not a specific goal, no. :) >>>>>>>> >>>>>>>> I don't expect that this will be a significant burden for most Swift >>>>>>>> programmers. Mainly, that's because this only affects classes that >>>>>>>> are exposed outside of a module, and the great majority of non-system >>>>>>>> classes in a typical Cocoa program are single-purpose leaf classes >>>>>>>> that — at most — expose a few methods to other subsystems. Swift >>>>>>>> doesn't really encourage you write complex classes that are primarily >>>>>>>> customized with subclassing; it encourages the heavy use of value >>>>>>>> types, and it encourages customization through protocols and >>>>>>>> functions. In fact, that's not really new to Swift, it's a general >>>>>>>> lesson from the last few decades of software development: composing >>>>>>>> smaller, independent systems through well-defined interfaces leads to >>>>>>>> better software than building monolithic systems whose behavior can >>>>>>>> only be defined in reference to the whole. >>>>>>>> >>>>>>>> I sympathize with the argument about wanting to fix bugs and add >>>>>>>> features via override, but that's never been maintainable in the long >>>>>>>> term; you always just end up with superclasses that everyone is >>>>>>>> terrified to touch because every subclass has its own invasive >>>>>>>> "fixes", and that's even when working within a single codebase. With >>>>>>>> libraries, you can pretty quickly get locked in to a specific version >>>>>>>> because your customizations don't work with new releases; either that, >>>>>>>> or the maintainer just decides that they can't fix of their mistakes >>>>>>>> and so goes off to rewrite it from scratch. Either way, it's not good >>>>>>>> for the ecosystem. >>>>>>>> >>>>>>>> Plus, as others have mentioned, Swift already provides a lot of >>>>>>>> features that don't allow overriding: structs, final, etc. You simply >>>>>>>> cannot rely on overriding to fix upstream bugs the way that you can in >>>>>>>> most traditional OO languages because not enough code flows through >>>>>>>> calls to overridable methods. We should not compromise the goal of >>>>>>>> promoting stronger and more maintainable library designs just to >>>>>>>> maintain this illusion. >>>>>>>> >>>>>>> >>>>>>> Thanks for continuing to make the case for this John. I really, really >>>>>>> hope the core team will accept the proposal (with revisions - the >>>>>>> problems with the keyword names are real). >>>>>> >>>>>> >>>>>> What about >>>>>> >>>>>> public internal(open) class Foo { ... } >>>>>> >>>>>> similar to >>>>>> >>>>>> public private(set) var foo: Foo >>>>>> >>>>>> This would also allow e.g. >>>>>> >>>>>> public fileprivate(open) class Foo { ... } >>>>> >>>>> This is an interesting idea. >>>>> >>>>> However it appears to have a problem in that it does not make >>>>> internal(open) the default for a public class or method if it behaves >>>>> consistently with private(set) (where the setter defaults to the same >>>>> visibility as the getter unless it is restricts further). >>>> >>>> True, but the main feature of the proposal is being able to separate >>>> control over visibility from control over the ability to subclass. This >>>> would still be possible, just the default would be different. >>> >>> Actually the main point of the proposal is to change the default. >> >> I don’t understand? Just changing the default would mean introducing >> something like final by default (which was another proposal). > > No, the point is to make sealed the default (not final). Final by default > never reached proposal status, it was only a discussion. I think I would be > happier with final as the default but sealed is a reasonable balance and is > well aligned with the rest of the defaults in Swift.
I was wondering if "reasonable" is a word I would use when having to make a choice between bad and worse. It is a concept I try to teach my 9 y/o: that between a number of unreasonable choices, the seamingly least unreasonable may still not be a reasonable one, even if selected. She is much too young to whatch Sophie's choice, which makes a too extreme depiction of this notion. > >> >> >>> It would still be useful without a new default but would have a >>> significantly smaller impact. The ecosystem advantages of the change in >>> default would not be realized. >> >> Hmm, not sure about that. > > Any ecosystem advantages derived from requiring explicit opt-in to external > subclasses (and presumably at least some thoughtfulness behind the choice) > would be nullified if sealed as an opt-in and the default remains the same. > >> >> -Thorsten >> >> >>> >>> It seems to me like most supporters of the proposal favor changing the >>> default and most opponents wouldn't view the additional control worth the >>> complexity it would introduce. >>> >>>> >>>> -Thorsten >>>> >>>>> >>>>> If we wanted to adopt this approach it would be good to also make setters >>>>> internal even when the property is marked public unless it is explicitly >>>>> marked public(set). This would behave consistently with the default of >>>>> sealed public classes and methods which would only become open if they >>>>> are explicit marked public(open). >>>>> >>>>> It would also tighten up another area of public API which arguably isn't >>>>> explicitly opted-in to today. Setters are automatically public for any >>>>> public property. API authors aren't required to explicitly state that >>>>> consumer should be able to mutate the property and are currently required >>>>> to opt-out if they do not want to allow that. >>>>> >>>>> -Matthew >>>>> >>>>>> >>>>>> -Thorsten >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> It will clearly ruffle a lot of feathers but is worth doing in this >>>>>>> case IMO. Especially since many commenters who are opposed do not seem >>>>>>> to grasp a couple of crucial points: >>>>>>> >>>>>>> 1. As you point out, the majority of the surface area of idiomatic >>>>>>> Swift APIs are unlikely to be impacted (value types, protocols, and >>>>>>> final classes). This is very likely to apply to future Swift-native >>>>>>> APIs from Apple regardless of the outcome of this proposal. >>>>>>> >>>>>>> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT). >>>>>>> >>>>>>> In the context of these facts, this proposal is not nearly as dramatic >>>>>>> a change as many seem to be suggesting. It just tightens up an >>>>>>> inconsistency in the language (the one area where public API contracts >>>>>>> are not explicitly opted-in to). >>>>>>> >>>>>>> -Matthew >>>>>>> >>>>>>>> John. >>>>>>>> >>>>>>>>> >>>>>>>>> Seriously though >>>>>>>>> >>>>>>>>>> Mine is the opinion of a library-maker, >>>>>>>>>> yours of the user of poorly designed/developed libraries. >>>>>>>>> >>>>>>>>> this kind of attitude on this list got to stop. >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution >>>>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>>>> >>>>>>>>>> Jean, IMO marking every class as subclassable means the creator does >>>>>>>>>> not care for you to design and develop a great library because s/he >>>>>>>>>> is >>>>>>>>>> not caring for the library at all. I right now have to go through the >>>>>>>>>> burdensome activity of marking too many classes/methods as final to >>>>>>>>>> prevent misuse of my libraries and find good design workarounds when >>>>>>>>>> I >>>>>>>>>> need to subclass internally what I don't want you to subclass. >>>>>>>>>> >>>>>>>>>> IMO the usage of a library is to be crafted/planned/designed by their >>>>>>>>>> developers not their users. Mine is the opinion of a library-maker, >>>>>>>>>> yours of the user of poorly designed/developed libraries. By pushing >>>>>>>>>> this proposal, developer of such libraries will have much burden to >>>>>>>>>> make/keep a poor library or will have to work on better >>>>>>>>>> design/implementation for it to suit its purpose. >>>>>>>>>> >>>>>>>>>> L >>>>>>>>>> >>>>>>>>>> On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution >>>>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>>>>> * What is your evaluation of the proposal? >>>>>>>>>>> >>>>>>>>>>> Strong -1 too. >>>>>>>>>>> >>>>>>>>>>> I can’t count the number of times it save my hours tone able to >>>>>>>>>>> override >>>>>>>>>>> arbitrary classes and methods. >>>>>>>>>>> >>>>>>>>>>> Sometimes to simply add log point to understand how the API work. >>>>>>>>>>> Other >>>>>>>>>>> times to workaround bugs in the library. Or even to extends the >>>>>>>>>>> library in a >>>>>>>>>>> way that the author did not intent in the first place, but that was >>>>>>>>>>> perfectly supported anyway. >>>>>>>>>>> >>>>>>>>>>> I already see how libraries author will react to that new default. >>>>>>>>>>> They will >>>>>>>>>>> either don’t care and mark all classes as subclassable, or find to >>>>>>>>>>> burdensome to get subclassability right and prohibit subclassing all >>>>>>>>>>> classes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >>>>>>>>>>> <swift-evolution@swift.org> a écrit : >>>>>>>>>>> >>>>>>>>>>> * What is your evaluation of the proposal? >>>>>>>>>>> >>>>>>>>>>> A **strong** -1 >>>>>>>>>>> >>>>>>>>>>> First, I have often found that you can’t always predict the way >>>>>>>>>>> which >>>>>>>>>>> something will need to be extended. You think you know, but are >>>>>>>>>>> then >>>>>>>>>>> surprised by creative uses. My favorite features of Swift/Cocoa >>>>>>>>>>> involve >>>>>>>>>>> retroactive modeling. >>>>>>>>>>> >>>>>>>>>>> Second, I don’t think this proposal will achieve its stated >>>>>>>>>>> objective of >>>>>>>>>>> forcing people to think about subclassing more. It will just add >>>>>>>>>>> confusing >>>>>>>>>>> boilerplate. >>>>>>>>>>> >>>>>>>>>>> Things like Swift optionals work well because they make the (often >>>>>>>>>>> forgotten) choices explicit in the context that they are used. In >>>>>>>>>>> the world >>>>>>>>>>> of Human Factors, we call it a forcing function. This proposal has >>>>>>>>>>> the >>>>>>>>>>> inverse structure, and will be ineffective, because the “forcing” >>>>>>>>>>> part of it >>>>>>>>>>> shows up in a different context (i.e. trying to use a framework) >>>>>>>>>>> than the >>>>>>>>>>> decision is being made in (writing the framework). This type of >>>>>>>>>>> thinking >>>>>>>>>>> leads to things like Java and the DMV. >>>>>>>>>>> >>>>>>>>>>> As Tino said: >>>>>>>>>>> >>>>>>>>>>> No matter what the defaults are, good libraries are hard to build, >>>>>>>>>>> so I >>>>>>>>>>> predict this proposal would not only fail in increasing framework >>>>>>>>>>> quality, >>>>>>>>>>> but also will make it much harder for users of those frameworks to >>>>>>>>>>> work >>>>>>>>>>> around their flaws, which are just a natural part of every software. >>>>>>>>>>> >>>>>>>>>>> I think he is right on here. Those who were prone to be thoughtful >>>>>>>>>>> about >>>>>>>>>>> their design would have been anyway. Those who are not thoughtful >>>>>>>>>>> about >>>>>>>>>>> their design will just leave these annotations off… leaving us with >>>>>>>>>>> no >>>>>>>>>>> recourse to extend/modify classes. When people complain, they will >>>>>>>>>>> add the >>>>>>>>>>> annotations without actually thinking about the meaning (i.e. stack >>>>>>>>>>> overflow >>>>>>>>>>> / the fixit tells me I need to add this word to make the compiler >>>>>>>>>>> happy). >>>>>>>>>>> All this does is put framework users at the mercy of the framework >>>>>>>>>>> writers. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Finally, this proposal is missing important aspects of the problem >>>>>>>>>>> space. >>>>>>>>>>> If we truly want to solve the issue of subclassing, we need to >>>>>>>>>>> consider all >>>>>>>>>>> of the common issues which arise. Looking at the cocoa >>>>>>>>>>> documentation you >>>>>>>>>>> will see several types of annotations: >>>>>>>>>>> 1) This method MUST be overridden >>>>>>>>>>> 2) This method should NOT be overridden >>>>>>>>>>> 3) This method MUST be called >>>>>>>>>>> 3) This method should NOT be called except by subclasses >>>>>>>>>>> 4) This method should NOT be called except by a method override >>>>>>>>>>> calling >>>>>>>>>>> super >>>>>>>>>>> 5) This method MUST call super >>>>>>>>>>> 6) Overrides of this method should NOT call super >>>>>>>>>>> >>>>>>>>>>> If we are attempting to bring thoughtfulness to the design of >>>>>>>>>>> classes, I >>>>>>>>>>> would like to see things be extendable by default, but with >>>>>>>>>>> annotations that >>>>>>>>>>> thoughtful framework designers can use to designate how a >>>>>>>>>>> particular method >>>>>>>>>>> should be used. In most cases, it should not explicitly forbid the >>>>>>>>>>> end user >>>>>>>>>>> from subclassing, but require them to acknowledge that what they >>>>>>>>>>> are doing >>>>>>>>>>> is not intended by the framework. (e.g. "unsafe override func"…). >>>>>>>>>>> That >>>>>>>>>>> would feel 1000x more swifty to me. Opt-out safety. >>>>>>>>>>> >>>>>>>>>>> * Is the problem being addressed significant enough to warrant a >>>>>>>>>>> change to >>>>>>>>>>> Swift? >>>>>>>>>>> >>>>>>>>>>> No. It doesn’t actually solve the problem... and I haven’t actually >>>>>>>>>>> run into >>>>>>>>>>> this problem in the real world. >>>>>>>>>>> >>>>>>>>>>> * Does this proposal fit well with the feel and direction of Swift? >>>>>>>>>>> >>>>>>>>>>> No, it gives Swift more of a feeling of busywork and unnecessary >>>>>>>>>>> boilerplate >>>>>>>>>>> while failing to achieve its objective. It goes against the >>>>>>>>>>> retroactive >>>>>>>>>>> modeling allowed by other areas of Swift. >>>>>>>>>>> >>>>>>>>>>> * If you have used other languages or libraries with a similar >>>>>>>>>>> feature, how >>>>>>>>>>> do you feel that this proposal compares to those? >>>>>>>>>>> >>>>>>>>>>> I tend to avoid languages which require this sort of thing. In >>>>>>>>>>> other >>>>>>>>>>> languages that lock things down, there is a need to unlock things >>>>>>>>>>> soon after >>>>>>>>>>> (e.g. friend classes). >>>>>>>>>>> >>>>>>>>>>> I predict the same thing will happen here. People will quickly be >>>>>>>>>>> asking >>>>>>>>>>> for the ability to patch/override in cases where the framework >>>>>>>>>>> designer was >>>>>>>>>>> wrong. That shows a problem inherent with the design... >>>>>>>>>>> >>>>>>>>>>> * How much effort did you put into your review? A glance, a quick >>>>>>>>>>> reading, >>>>>>>>>>> or an in-depth study? >>>>>>>>>>> >>>>>>>>>>> Read the proposal & discussion. Read earlier discussions around >>>>>>>>>>> access >>>>>>>>>>> control that touched on this subject as well. I have been designing >>>>>>>>>>> frameworks for years. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> Hello Swift community, >>>>>>>>>>> >>>>>>>>>>> The review of "SE-0117: Default classes to be non-subclassable >>>>>>>>>>> publicly" >>>>>>>>>>> begins now and runs through July 11. The proposal is available here: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md >>>>>>>>>>> >>>>>>>>>>> Reviews are an important part of the Swift evolution process. All >>>>>>>>>>> reviews >>>>>>>>>>> should be sent to the swift-evolution mailing list at >>>>>>>>>>> >>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>> >>>>>>>>>>> or, if you would like to keep your feedback private, directly to >>>>>>>>>>> the review >>>>>>>>>>> manager. >>>>>>>>>>> >>>>>>>>>>> What goes into a review? >>>>>>>>>>> >>>>>>>>>>> The goal of the review process is to improve the proposal under >>>>>>>>>>> review >>>>>>>>>>> through constructive criticism and contribute to the direction of >>>>>>>>>>> Swift. >>>>>>>>>>> When writing your review, here are some questions you might want to >>>>>>>>>>> answer >>>>>>>>>>> in your review: >>>>>>>>>>> >>>>>>>>>>> * What is your evaluation of the proposal? >>>>>>>>>>> * Is the problem being addressed significant enough to warrant a >>>>>>>>>>> change to >>>>>>>>>>> Swift? >>>>>>>>>>> * Does this proposal fit well with the feel and direction of >>>>>>>>>>> Swift? >>>>>>>>>>> * If you have used other languages or libraries with a similar >>>>>>>>>>> feature, how >>>>>>>>>>> do you feel that this proposal compares to those? >>>>>>>>>>> * How much effort did you put into your review? A glance, a >>>>>>>>>>> quick reading, >>>>>>>>>>> or an in-depth study? >>>>>>>>>>> >>>>>>>>>>> More information about the Swift evolution process is available at >>>>>>>>>>> >>>>>>>>>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> >>>>>>>>>>> -Chris Lattner >>>>>>>>>>> Review Manager >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >> > _______________________________________________ > 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