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.
>
>
>> 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
