> Am 08.07.2016 um 17:24 schrieb Matthew Johnson <[email protected]>: > > > > Sent from my iPad > > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz <[email protected] > <mailto:[email protected]>> wrote: > >> >> >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson <[email protected] >> <mailto:[email protected]>>: >> >>> >>> >>> Sent from my iPad >>> >>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> 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). > 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. -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 >>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>>>>> >>>>>>>>> <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 >>>>>>>>> <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 >>>>>>>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> -Chris Lattner >>>>>>>>> Review Manager >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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> >>>>>>> _______________________________________________ >>>>>>> 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> >>>>>> >>>>>> _______________________________________________ >>>>>> 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> >>>>> _______________________________________________ >>>>> 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>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
