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
