Sent from my iPad
> On Jul 8, 2016, at 12:32 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Jul 8, 2016, at 8:24 AM, Matthew Johnson <matt...@anandabits.com> wrote: >>> 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. 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. >> >> 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. > > I would say that the opponents so far have been split about whether they > would like this as an opt-in feature. Maybe. I admit this was just my impression and not a careful analysis. > >>>> 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. > > I've thought about this, but overall I think the current behavior is right > here. It's reasonable for API authors to understand that making a property > public means making it publicly settable. That's reasonable. My primary point is that if go in this direction I would prefer consistent behavior of 'open' and 'set'. I really want sealed to be the default so I would argue against this syntax is we aren't willing to change how 'set' works. The idea of changing 'set' is a secondary point demonstrating how to make the syntax suggestion work in a consistent manner. I wouldn't be opposed to it and a supporting argument is possible, but I don't think this a critical change. > > John. > >>>> >>>> -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