Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

I think you missed that I actually agree with all your points.

My point was merely regarding “pre-breaking” which I thought wasn’t a relevant 
term. I think a far more appropriate term is “overly limiting”. We are 
discussing semantics, nonetheless.

I actually support the idea that you should be able to subclass classes by 
default, with some form of acknowledgement that “I know this wasn’t meant to be 
subclassed, but I’m going to anyway.” This frees framework developers from the 
idea that it was “promised” to be able to work, and also frees a developer from 
the chains of an overly constrained development environment.

- Rod


> On 12 Jul 2016, at 9:00 AM, Jonathan Hull  wrote:
> 
>> 
>> On Jul 10, 2016, at 7:48 PM, Rod Brown  wrote:
>> 
>>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
>>> 
>>> It is pre-breaking in that it is the exact same code that doesn’t work in 
>>> both cases (only in the pre-breaking case, a bunch of other code also 
>>> doesn’t work).  I know it feels different because it “was never possible” 
>>> vs our change being the cause, but it is one of those things like me giving 
>>> you $5 or giving you $10 and later taking back $5.  As humans we are loss 
>>> averse so we devise strategies to hide the loss from ourselves.
>> 
>> I completely disagree with this.
>> 
>> Not providing someone something due to risk of breakage is not the same 
>> thing as “giving it and taking it away”. We don’t build bridges out of spare 
>> parts and tell people “We build it but we expect it to break at some stage, 
>> so use with caution.” You either build it correctly, or you don’t let people 
>> cross the bridge. At All.
>> 
>> This isn’t about “loss averse”. This is about risk management.
>> 
>> Where does the line lie on risk? That’s ultimately something the core team 
>> will have to decide.
> 
> My point is that you are completely ignoring an entire class of risk that has 
> a real-world $$$ cost.  Every time I have to use a framework under this 
> proposal, I am now completely at the mercy of the author.  In the case of 
> open source frameworks I can at least make a fork, but for closed source 
> frameworks (often from large companies where us using their framework has 
> been negotiated by the bosses) you have now just added weeks to my 
> development cycle while I wait for 
> big-company-who-doesn’t-really-care-that-much to update their stuff. (sure I 
> can work on other things during that time, but delaying a launch isn’t free)
> 
> Are you offering to explain to my boss/client why I can’t add the feature in 
> a reasonable timeframe like I can with Objective C frameworks?  That it may 
> not even be possible now in Swift even though the Android guy just did it in 
> a few hours?  
> 
> Do you know what I am going to tell my boss/client?  "Don’t use Swift for 
> frameworks” and “Try to avoid partnering with companies that have Swift 
> frameworks”.  "It is too much of a risk".  "We are giving them too much 
> control over the future of our product…"  I mean, it even affects the prices 
> that companies can charge for crappy frameworks. If I am asking for a bunch 
> of features that I NEED them to add to provide a basic feature, that affects 
> negotiations/price (vs a world where I can add it myself if needed).  
> Sealed-by-default gives them leverage.
> 
> To use your bridge analogy, which is better in the case that you haven’t 
> provided a bridge for me:
> 1) I build my own bridge knowing that I will need to maintain it periodically 
> (usually on a predictable schedule)
> 2) Have everyone wait for 6 months (loosing $ the whole time) while I plead 
> with you to build the bridge for me.
> 
> By definition, the least thought through frameworks are the ones most likely 
> to need workarounds, but under this proposal, they are also the ones we will 
> be unable to fix.  I think some people think that this proposal will make 
> them fix those frameworks or make them disappear… but they are often from big 
> brand name companies, who don’t care that much because tech isn’t their main 
> business.  In my experience, we can get the changes we need, but it takes 
> anywhere from 2 months to a year.  Being able to patch in a stop-gap while we 
> are waiting is very important for the health of the business.
> 
> For example, I had a recent client that called me in a panic (unfortunately I 
> have somehow gotten a reputation as someone to call for impossible tasks) 
> because they had a demo they needed to show for a potential multimillion 
> dollar deal and it just wasn’t working.  The tech they had used as a base 
> wasn’t doing what it was supposed to… and the fixes were 3-6 months away (the 
> demo was a week and a half away).  I would call the support guy for the tech, 
> and they would tell me “that isn’t possible yet. Just wait for the update”.  
> I would call them back a couple of hours later saying “If someone else 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution 
> :
> 
> If you can’t trust a developer, how could you use its library ?
I guess you're getting this wrong, and maybe on purpose:
Thrusting a developer is competent and tries to do a good job is on a 
completely different scale than the faith that someone foresees the future and 
writes code without any errors.

> Using third-party code involve some kind of trusting, as you would have to 
> trust the developer to write reliable and efficient code, which is IMHO, far 
> more important than knowing if the developer carefully choose what can be 
> subclasses or not.
Very true — so wouldn't it better to concentrate on topics that help developers 
write this code, instead of building a bureaucracy that makes coding harder?

> And when you encounter a library where the dev choose to allow subclassing, 
> you will have far more trust than the code was design to be subclassed.
I have the impression that many supporters of the proposal would love to have 
the power to not only change a tiny part of the language, but all the people 
using it... luckily, this isn't true, and this would be a false feeling of 
security:
Even if you punish them, some developers will value the freedom of choice more 
than the tiny slight risk of harming someone who uses this liberty — and even 
the biggest bureaucrats won't get their inheritance-model right all the time...

> Some design patterns work better with subclassing than with protocol or 
> delegation. So I’m confident than library developers will ‘open’ there 
> classes if needed.

Would you allow others to put you in a cage, as long as they will open it if 
needed?
I wouldn't want that, even if that cage offered some protection.

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 12 juil. 2016 à 21:29, Jean-Denis Muys via swift-evolution 
>  a écrit :
> 
> * What is your evaluation of the proposal?
> 
> I am strongly opposed to that proposal. I am mostly a lurker on this list, 
> the volume of which I cannot cope with. However, I feel this proposal is 
> important enough that I decided to invest more time than usual.
> So I have read carefully the arguments presented here.
> And I am still opposed to the proposal.
> I believe no programmer, least of which myself, can be trusted with the 
> decision to reliably decide ahead of time that this or that class cannot or 
> will not be subclassed.

If you can’t trust a developer, how could you use its library ? Using 
third-party code involve some kind of trusting, as you would have to trust the 
developer to write reliable and efficient code, which is IMHO, far more 
important than knowing if the developer carefully choose what can be subclasses 
or not.

And when you encounter a library where the dev choose to allow subclassing, you 
will have far more trust than the code was design to be subclassed.

Some design patterns work better with subclassing than with protocol or 
delegation. So I’m confident than library developers will ‘open’ there classes 
if needed.

> So strong -1 for me.
>  
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> 
> I don't think the problem is a problem at all.
>  
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Not in my mind. Swift aims for safety, but not at the price of inflexibility
> 
> 
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> I would compare it for example to the decision for the C++ developer to mark 
> methods virtual or not, with the usual recommendation to mark everything 
> virtual, especially the destructor
> 
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> I read it and ready carefully the debate on this list.
>  
> 
> On Tue, Jul 12, 2016 at 5:36 PM, Jon Akhtar via swift-evolution 
> > wrote:
> I completely agree, the programmer should have as much power as we can
> give them, even if it means allowing them to shoot themselves in the foot,
> because at the end of the day Swift isn¹t an academic exercise, it is a
> real world programming language, so it should be optimized for solving
> real world problems not having some kind of technical, philosophical, and
> stylistic perfection when those come at the cost of the former.
> 
> So -1
> 
> -Jon
> 
> On 7/11/16, 16:00, "swift-evolution-boun...@swift.org 
>  on behalf of
> Jonathan Hull via swift-evolution"   on
> behalf of swift-evolution@swift.org > wrote:
> 
> >
> >> On Jul 10, 2016, at 7:48 PM, Rod Brown  >> > wrote:
> >>
> >>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  >>> > wrote:
> >>>
> >>> It is pre-breaking in that it is the exact same code that doesn¹t work
> >>>in both cases (only in the pre-breaking case, a bunch of other code
> >>>also doesn¹t work).  I know it feels different because it ³was never
> >>>possible² vs our change being the cause, but it is one of those things
> >>>like me giving you $5 or giving you $10 and later taking back $5.  As
> >>>humans we are loss averse so we devise strategies to hide the loss from
> >>>ourselves.
> >>
> >> I completely disagree with this.
> >>
> >> Not providing someone something due to risk of breakage is not the same
> >>thing as ³giving it and taking it away². We don¹t build bridges out of
> >>spare parts and tell people ³We build it but we expect it to break at
> >>some stage, so use with caution.² You either build it correctly, or you
> >>don¹t let people cross the bridge. At All.
> >>
> >> This isn¹t about ³loss averse². This is about risk management.
> >>
> >> Where does the line lie on risk? That¹s ultimately something the core
> >>team will have to decide.
> >
> >My point is that you are completely ignoring an entire class of risk that
> >has a real-world $$$ cost.  Every time I have to use a framework under
> >this proposal, I am now completely at the mercy of the author.  In the
> >case of open source frameworks I can at least make a fork, but for closed
> >source frameworks (often from large companies where us using their
> >framework has been negotiated by the bosses) you have now just added
> >weeks to my development cycle while I wait for
> >big-company-who-doesn¹t-really-care-that-much to update their stuff.
> >(sure I can work on other things during that time, but delaying a 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[David Owens II via swift-evolution]

> I believe no programmer, least of which myself, can be trusted with the 
> decision to reliably decide ahead of time that this or that class cannot or 
> will not be subclassed.
> So strong -1 for me.

I just don’t get this line of reasoning. Can a programmer be trusted with 
determining if a type should be declared as a struct vs. a class? If I choose 
to implement an API construct with a struct, you’ll be the exact same position 
that this proposal puts you in with classes as well.

I’m a big +1 for this proposal. The default annotations on types should set up 
code to be as future-proof as possible without putting someone in a bad spot 
resilience-wise simply because they forgot to add the restriction before 
shipping.

This proposal also does *not* disallow language features that allow unsafe 
constructs to be added later. Even with this proposal, it’s still possible to 
add the __unsafe_really_subclass_even_though_its_bad construct. It requires 
additional metadata to be kept around by the compiler so that any optimizations 
that may have removed the dynamic dispatching of functions calls through the 
inheritance chain to be kept, but it’s still possible.

-David 


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Denis Muys via swift-evolution]

>
> * What is your evaluation of the proposal?
>

I am strongly opposed to that proposal. I am mostly a lurker on this list,
the volume of which I cannot cope with. However, I feel this proposal is
important enough that I decided to invest more time than usual.
So I have read carefully the arguments presented here.
And I am still opposed to the proposal.
I believe no programmer, least of which myself, can be trusted with the
decision to reliably decide ahead of time that this or that class cannot or
will not be subclassed.
So strong -1 for me.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

I don't think the problem is a problem at all.


> * Does this proposal fit well with the feel and direction of Swift?
>

Not in my mind. Swift aims for safety, but not at the price of inflexibility


* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

I would compare it for example to the decision for the C++ developer to
mark methods virtual or not, with the usual recommendation to mark
everything virtual, especially the destructor

* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I read it and ready carefully the debate on this list.


On Tue, Jul 12, 2016 at 5:36 PM, Jon Akhtar via swift-evolution <
swift-evolution@swift.org> wrote:

> I completely agree, the programmer should have as much power as we can
> give them, even if it means allowing them to shoot themselves in the foot,
> because at the end of the day Swift isn¹t an academic exercise, it is a
> real world programming language, so it should be optimized for solving
> real world problems not having some kind of technical, philosophical, and
> stylistic perfection when those come at the cost of the former.
>
> So -1
>
> -Jon
>
> On 7/11/16, 16:00, "swift-evolution-boun...@swift.org on behalf of
> Jonathan Hull via swift-evolution"  behalf of swift-evolution@swift.org> wrote:
>
> >
> >> On Jul 10, 2016, at 7:48 PM, Rod Brown 
> wrote:
> >>
> >>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
> >>>
> >>> It is pre-breaking in that it is the exact same code that doesn¹t work
> >>>in both cases (only in the pre-breaking case, a bunch of other code
> >>>also doesn¹t work).  I know it feels different because it ³was never
> >>>possible² vs our change being the cause, but it is one of those things
> >>>like me giving you $5 or giving you $10 and later taking back $5.  As
> >>>humans we are loss averse so we devise strategies to hide the loss from
> >>>ourselves.
> >>
> >> I completely disagree with this.
> >>
> >> Not providing someone something due to risk of breakage is not the same
> >>thing as ³giving it and taking it away². We don¹t build bridges out of
> >>spare parts and tell people ³We build it but we expect it to break at
> >>some stage, so use with caution.² You either build it correctly, or you
> >>don¹t let people cross the bridge. At All.
> >>
> >> This isn¹t about ³loss averse². This is about risk management.
> >>
> >> Where does the line lie on risk? That¹s ultimately something the core
> >>team will have to decide.
> >
> >My point is that you are completely ignoring an entire class of risk that
> >has a real-world $$$ cost.  Every time I have to use a framework under
> >this proposal, I am now completely at the mercy of the author.  In the
> >case of open source frameworks I can at least make a fork, but for closed
> >source frameworks (often from large companies where us using their
> >framework has been negotiated by the bosses) you have now just added
> >weeks to my development cycle while I wait for
> >big-company-who-doesn¹t-really-care-that-much to update their stuff.
> >(sure I can work on other things during that time, but delaying a launch
> >isn¹t free)
> >
> >Are you offering to explain to my boss/client why I can¹t add the feature
> >in a reasonable timeframe like I can with Objective C frameworks?  That
> >it may not even be possible now in Swift even though the Android guy just
> >did it in a few hours?
> >
> >Do you know what I am going to tell my boss/client?  "Don¹t use Swift for
> >frameworks² and ³Try to avoid partnering with companies that have Swift
> >frameworks².  "It is too much of a risk".  "We are giving them too much
> >control over the future of our productŠ"  I mean, it even affects the
> >prices that companies can charge for crappy frameworks. If I am asking
> >for a bunch of features that I NEED them to add to provide a basic
> >feature, that affects negotiations/price (vs a world where I can add it
> >myself if needed).  Sealed-by-default gives them leverage.
> >
> >To use your bridge analogy, which is better in the case that you haven¹t
> >provided a bridge for me:
> >1) I build my own bridge knowing that I will need to maintain 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Max Desiatov via swift-evolution]

-1. I strongly oppose this proposal and think that it adds substantial
complexity to the language with introduction of yet another set of keywords
that are similar to `final` and visibility modifiers, but work differently.
The proposal doesn't cover the behaviour of `final` and having `final` and
`overridable`/`subclassable` in the language at the same time would make it
more complex and harder to learn.

> 06.07.2016 01:11 Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
> >
> > 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[David Sweeris via swift-evolution]

-1 for this proposal, but +1 for solving the issues it raises

Regardless of what ends up being the defaults, I’m a very strong -1 on 
conflating visibility and subclassability/extendability.

- Dave Sweeris

> On Jul 5, 2016, at 6:11 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

+1 for the feature, +0.5 for being it the default and -1 for they syntax.
I'd prefer `open`, maybe `public(open)` or probably better `public open`.

I think library design is important and so this is a problem worth solving. I 
read the proposal and followed the discussion.

-Thorsten 

> Am 06.07.2016 um 01:11 schrieb Chris Lattner via swift-evolution 
> :
> 
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jonathan Hull via swift-evolution]

> On Jul 10, 2016, at 7:48 PM, Rod Brown  wrote:
> 
>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
>> 
>> It is pre-breaking in that it is the exact same code that doesn’t work in 
>> both cases (only in the pre-breaking case, a bunch of other code also 
>> doesn’t work).  I know it feels different because it “was never possible” vs 
>> our change being the cause, but it is one of those things like me giving you 
>> $5 or giving you $10 and later taking back $5.  As humans we are loss averse 
>> so we devise strategies to hide the loss from ourselves.
> 
> I completely disagree with this.
> 
> Not providing someone something due to risk of breakage is not the same thing 
> as “giving it and taking it away”. We don’t build bridges out of spare parts 
> and tell people “We build it but we expect it to break at some stage, so use 
> with caution.” You either build it correctly, or you don’t let people cross 
> the bridge. At All.
> 
> This isn’t about “loss averse”. This is about risk management.
> 
> Where does the line lie on risk? That’s ultimately something the core team 
> will have to decide.

My point is that you are completely ignoring an entire class of risk that has a 
real-world $$$ cost.  Every time I have to use a framework under this proposal, 
I am now completely at the mercy of the author.  In the case of open source 
frameworks I can at least make a fork, but for closed source frameworks (often 
from large companies where us using their framework has been negotiated by the 
bosses) you have now just added weeks to my development cycle while I wait for 
big-company-who-doesn’t-really-care-that-much to update their stuff. (sure I 
can work on other things during that time, but delaying a launch isn’t free)

Are you offering to explain to my boss/client why I can’t add the feature in a 
reasonable timeframe like I can with Objective C frameworks?  That it may not 
even be possible now in Swift even though the Android guy just did it in a few 
hours?  

Do you know what I am going to tell my boss/client?  "Don’t use Swift for 
frameworks” and “Try to avoid partnering with companies that have Swift 
frameworks”.  "It is too much of a risk".  "We are giving them too much control 
over the future of our product…"  I mean, it even affects the prices that 
companies can charge for crappy frameworks. If I am asking for a bunch of 
features that I NEED them to add to provide a basic feature, that affects 
negotiations/price (vs a world where I can add it myself if needed).  
Sealed-by-default gives them leverage.

To use your bridge analogy, which is better in the case that you haven’t 
provided a bridge for me:
1) I build my own bridge knowing that I will need to maintain it periodically 
(usually on a predictable schedule)
2) Have everyone wait for 6 months (loosing $ the whole time) while I plead 
with you to build the bridge for me.

By definition, the least thought through frameworks are the ones most likely to 
need workarounds, but under this proposal, they are also the ones we will be 
unable to fix.  I think some people think that this proposal will make them fix 
those frameworks or make them disappear… but they are often from big brand name 
companies, who don’t care that much because tech isn’t their main business.  In 
my experience, we can get the changes we need, but it takes anywhere from 2 
months to a year.  Being able to patch in a stop-gap while we are waiting is 
very important for the health of the business.

For example, I had a recent client that called me in a panic (unfortunately I 
have somehow gotten a reputation as someone to call for impossible tasks) 
because they had a demo they needed to show for a potential multimillion dollar 
deal and it just wasn’t working.  The tech they had used as a base wasn’t doing 
what it was supposed to… and the fixes were 3-6 months away (the demo was a 
week and a half away).  I would call the support guy for the tech, and they 
would tell me “that isn’t possible yet. Just wait for the update”.  I would 
call them back a couple of hours later saying “If someone else asks, here is 
how I did it…”  Was that code beautiful? No.  Did I get all the features in 
that demo working?  Yes, with something like 1 hour to spare.  The demo went 
very very well.

Should I have let that deal fall through because it wasn’t the “proper” 
ideological way to write code?  Sometimes things just need to get done and 
there isn’t another way….  A few people have suggested that these types of 
concerns aren’t relevant, but I find them very relevant to my everyday life.  
This is the first proposal with the ability to actually cost me (and my 
clients) money.

I am completely ok with needing to type “unsafe” (or similar) to acknowledge 
and take responsibility for my actions in those situations.  I understand those 
modifications might break when the framework is finally updated in 3-6 months 
(hopefully we can 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Kurt Werle via swift-evolution]

-1

On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

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

I've used classes that were marked final that I wish were not.
I've never used a class that was not final that I wish was marked so.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

I don't think the 'problem' described is a problem.

If you expose a class, you should think about how it might be subclassed.
In the very rare (and still too frequent) case when something should not be
subclassed, you should document it that way and explain why.


> * Does this proposal fit well with the feel and direction of Swift?
>

I hope not.

Kurt
-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose via swift-evolution]

> On Jul 11, 2016, at 11:16, Goffredo Marocchi  wrote:
> 
> So either open by default and sealed optionally or sealed by default and no 
> escape hatch?

I think there are two separate decisions in here:

- Open by default or sealed by default?
- If sealed, can the seal be broken by clients?

These decisions aren’t independent ("if sealed is the default, it’s more 
important for clients to be able to break it, since it might be an accident”, 
perhaps), but either can be implemented independently.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ricardo Parada via swift-evolution]

WebObjects is one of the frameworks I was referring to without actually naming 
it. 

After Apple stopped supporting WebObjects we have been able to fix, extend and 
enhance it all these years and has served us really well. It is an awesome 
framework. I really wish that Swift had a framework like it. But Swift's 
limited reflection is lacking and is crucial for implementing a framework like 
WebObjects. 

Had WebObjects been designed with sealed classes, our hands would have been 
tied for all the many apps and systems that use it. 

I am hoping that if this proposal gets approved that libraries such as these 
get designed as subclassable. That to me is much more valuable, at least for 
these types of libraries. 

I think that in the long term libraries will sort themselves out. A well 
designed subclassable library will have more value. 




> On Jul 11, 2016, at 12:49 PM, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 11, 2016, at 12:53 PM, Tino Heth <2...@gmx.de> wrote:
>> 
>> 
>>> You do realize that then itunes store used to (i don't know hese days) for 
>>> many years run on java, despite objc being such a more advanced 
>>> environment. ;-)
>> well, from my experience, app developers are running circles around the 
>> itunes store all the time ;-)
> 
> Better yet... I once had lunch with the now defunct java team and the guy who 
> did the java rewrite of webobjects... can you guess from what language? or 
> why they had to do it? 
> Still running circles?
> ;-)
> Cheers & thank u for the smiles...
> 
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

So either open by default and sealed optionally or sealed by default and no
escape hatch?

On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 2016/07/09 23:30、Matthew Johnson  のメール：
>
>
> This leaves the scenario of a case where you depend on a 3rd party,
> closed-source library written in Swift and where you cannot get (or use) a
> fix from the vendor for some reason.  This is a legitimate concern, but IMO
> it is not large enough to outweigh all of the advantages of making sealed
> the default.
>
> What are your thoughts on an ability for a way to force unseal a class
> that does need to be fixed, even if its temporary?
>
> Something like:
>
> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) {
> //Emits a scary compiler warning
> }
>
> Does that even seem feasible/possible, much less reasonable…?
> Though it would have to be a perhaps separate discussion, this comes to my
> mind as becoming necessary down the road, but maybe I’m wrong...
>
>
> I'm not opposed to something like this in principle, but I'm not sure how
> it would work in practice.  There was some discussion of something along
> these lines on the list at one point (I think Joe Groff had some ideas).
> However, I don't think this is possible if the optimizer takes advantage of
> the sealed status when the library is compiled.  I'll leave it to the
> compiler experts to comment further on feasibility.
>
>
> My technical analysis: It’s certainly implementable to have the optimizer
> *not* take advantage of the sealed status, and to allow some sort of
> “unsafe-break-the-seal” syntax. We’d have to be sure that anything that
> “can’t possibly happen without external subclassing” still at least
> generates a deterministic trap rather than memory corruption, but that’s
> probably doable.
>
> (I’ll leave it at that, without trying to argue a particular side.)
>
>
> I agree that this is implementable.  I would be very reluctant to do it,
> though; it amounts to writing off all of the performance advantages of the
> proposal.  (And possibly the semantic advantages as well, like being less
> restrictive about required initializers.)
>
> John.
>
>
>
>
> I have seen some comments about nontrivial complexity in Apple’s
> frameworks caused by apps subclassing where they should not have (i.e.
> classes that would be sealed if it were possible in Objective-C).  This is
> extremely unfortunate and it impacts everyone on Apple’s platforms.
>
> I wish I had links handy for you, but I don’t recall exactly where or when
> this was mentioned and don’t have time to dig them up right now.
>
> I see, thats reasonable… if those links are available somewhere I would
> definitely like to see them, it would be a good education for me…
>
>
> IIRC like Jordan Rose may have made some comments along these lines either
> on list or on Twitter if you want to search, but that is a fuzzy memory and
> could easily be wrong.  :)
>
>
> I don’t have anything handy (partially because some of it isn’t public
> knowledge), but it’s a well-known phenomenon within Apple that new OSs
> break third-party apps in strange ways because they are relying on being
> able to swizzle a non-public selector, or even on its existence. I’ll admit
> I don’t hear as much about intrusive subclassing, but that doesn’t mean
> Apple hasn’t made changes that assume no one subclasses a particular class.
>
> [For anyone who doesn’t know the term “method swizzling”: Objective-C
> allows you to replace a class’s implementation of a method at run-time,
> regardless of where the class or the replacement is defined.]
>
> Jordan
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>>> 
 2016/07/09 23:30、Matthew Johnson > のメール：
 
 This leaves the scenario of a case where you depend on a 3rd party, 
 closed-source library written in Swift and where you cannot get (or use) a 
 fix from the vendor for some reason.  This is a legitimate concern, but 
 IMO it is not large enough to outweigh all of the advantages of making 
 sealed the default.  
>>> What are your thoughts on an ability for a way to force unseal a class that 
>>> does need to be fixed, even if its temporary?
>>> 
>>> Something like:
>>> 
>>> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits 
>>> a scary compiler warning
>>> }
>>> 
>>> Does that even seem feasible/possible, much less reasonable…?
>>> Though it would have to be a perhaps separate discussion, this comes to my 
>>> mind as becoming necessary down the road, but maybe I’m wrong...
>> 
>> I'm not opposed to something like this in principle, but I'm not sure how it 
>> would work in practice.  There was some discussion of something along these 
>> lines on the list at one point (I think Joe Groff had some ideas).  However, 
>> I don't think this is possible if the optimizer takes advantage of the 
>> sealed status when the library is compiled.  I'll leave it to the compiler 
>> experts to comment further on feasibility.  
> 
> My technical analysis: It’s certainly implementable to have the optimizer not 
> take advantage of the sealed status, and to allow some sort of 
> “unsafe-break-the-seal” syntax. We’d have to be sure that anything that 
> “can’t possibly happen without external subclassing” still at least generates 
> a deterministic trap rather than memory corruption, but that’s probably 
> doable.
> 
> (I’ll leave it at that, without trying to argue a particular side.)

I agree that this is implementable.  I would be very reluctant to do it, 
though; it amounts to writing off all of the performance advantages of the 
proposal.  (And possibly the semantic advantages as well, like being less 
restrictive about required initializers.)

John.

> 
> 
>>> 
 I have seen some comments about nontrivial complexity in Apple’s 
 frameworks caused by apps subclassing where they should not have (i.e. 
 classes that would be sealed if it were possible in Objective-C).  This is 
 extremely unfortunate and it impacts everyone on Apple’s platforms.
 
 I wish I had links handy for you, but I don’t recall exactly where or when 
 this was mentioned and don’t have time to dig them up right now.
>>> I see, thats reasonable… if those links are available somewhere I would 
>>> definitely like to see them, it would be a good education for me…
>> 
>> IIRC like Jordan Rose may have made some comments along these lines either 
>> on list or on Twitter if you want to search, but that is a fuzzy memory and 
>> could easily be wrong.  :)
> 
> I don’t have anything handy (partially because some of it isn’t public 
> knowledge), but it’s a well-known phenomenon within Apple that new OSs break 
> third-party apps in strange ways because they are relying on being able to 
> swizzle a non-public selector, or even on its existence. I’ll admit I don’t 
> hear as much about intrusive subclassing, but that doesn’t mean Apple hasn’t 
> made changes that assume no one subclasses a particular class.
> 
> [For anyone who doesn’t know the term “method swizzling”: Objective-C allows 
> you to replace a class’s implementation of a method at run-time, regardless 
> of where the class or the replacement is defined.]
> 
> Jordan
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 12:53 PM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> You do realize that then itunes store used to (i don't know hese days) for 
>> many years run on java, despite objc being such a more advanced environment. 
>> ;-)
> well, from my experience, app developers are running circles around the 
> itunes store all the time ;-)

Better yet... I once had lunch with the now defunct java team and the guy who 
did the java rewrite of webobjects... can you guess from what language? or why 
they had to do it? 
Still running circles?
;-)
Cheers & thank u for the smiles...


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 11 juil. 2016 à 09:39, Tino Heth via swift-evolution 
>  a écrit :
> 
> 
>> With the existence of Swift on the server, dynamically linked, independently 
>> distributed frameworks will not be an Apple-only issue - this extends beyond 
>> Apple's OS X-based platforms towards how dynamic frameworks link against 
>> each other as if they are to be distributed separately.
>> 
>> It is short sighted to suggest that all Swift deployments will be under 
>> Apple's control.
> I'm really looking forward for server-side Swift — I'm planning for years to 
> extend my portfolio in that direction, and Swift could really push that 
> diversification.

Server side swift is already alive:  https://developer.ibm.com/swift/

> But I had a concrete reason for interest in writing my own backend-code:
> Server-side was imho broken on large scale, and it still isn't fixed yet… I 
> can run circles around those poor Java-developers who have to fight crusted 
> structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).*
> It seems to me I'm not alone with my opinion, because there are already 
> alternatives on the rise:
> Look at Docker — it's a huge success, because it not only takes application 
> and libraries to build a robust unit; it even includes a whole OS!
> 
> On iOS, it already hurts when you have a bunch of Swift-Apps which all have 
> the stdlib bundled — but on the server, this doesn't matter, and I'm 
> convinced it would be a bad move to propagate shared frameworks.
> 
> - Tino
> 
> * of course, there are agile alternatives — but in my environment, most of 
> the big players wouldn't even consider something like Rails
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> You do realize that then itunes store used to (i don't know hese days) for 
> many years run on java, despite objc being such a more advanced environment. 
> ;-)
well, from my experience, app developers are running circles around the itunes 
store all the time ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 9:39 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> With the existence of Swift on the server, dynamically linked, independently 
>> distributed frameworks will not be an Apple-only issue - this extends beyond 
>> Apple's OS X-based platforms towards how dynamic frameworks link against 
>> each other as if they are to be distributed separately.
>> 
>> It is short sighted to suggest that all Swift deployments will be under 
>> Apple's control.
> I'm really looking forward for server-side Swift — I'm planning for years to 
> extend my portfolio in that direction, and Swift could really push that 
> diversification.
> 
> But I had a concrete reason for interest in writing my own backend-code:
> Server-side was imho broken on large scale, and it still isn't fixed yet… I 
> can run circles around those poor Java-developers who have to fight crusted 
> structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).*

You do realize that then itunes store used to (i don't know hese days) for many 
years run on java, despite objc being such a more advanced environment. ;-)


> It seems to me I'm not alone with my opinion, because there are already 
> alternatives on the rise:
> Look at Docker — it's a huge success, because it not only takes application 
> and libraries to build a robust unit; it even includes a whole OS!
> 
> On iOS, it already hurts when you have a bunch of Swift-Apps which all have 
> the stdlib bundled — but on the server, this doesn't matter, and I'm 
> convinced it would be a bad move to propagate shared frameworks.
> 
> - Tino
> 
> * of course, there are agile alternatives — but in my environment, most of 
> the big players wouldn't even consider something like Rails
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> With the existence of Swift on the server, dynamically linked, independently 
> distributed frameworks will not be an Apple-only issue - this extends beyond 
> Apple's OS X-based platforms towards how dynamic frameworks link against each 
> other as if they are to be distributed separately.
> 
> It is short sighted to suggest that all Swift deployments will be under 
> Apple's control.
I'm really looking forward for server-side Swift — I'm planning for years to 
extend my portfolio in that direction, and Swift could really push that 
diversification.

But I had a concrete reason for interest in writing my own backend-code:
Server-side was imho broken on large scale, and it still isn't fixed yet… I can 
run circles around those poor Java-developers who have to fight crusted 
structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).*
It seems to me I'm not alone with my opinion, because there are already 
alternatives on the rise:
Look at Docker — it's a huge success, because it not only takes application and 
libraries to build a robust unit; it even includes a whole OS!

On iOS, it already hurts when you have a bunch of Swift-Apps which all have the 
stdlib bundled — but on the server, this doesn't matter, and I'm convinced it 
would be a bad move to propagate shared frameworks.

- Tino

* of course, there are agile alternatives — but in my environment, most of the 
big players wouldn't even consider something like Rails

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Am 11.07.2016 um 03:45 schrieb Rod Brown :
> 
> That said, I actually think you have a good point however that “sealed” 
> should be able to be overridden, either in a patch capacity or an “unsafe” 
> capacity. Should this become final at a later point, you have acknowledged 
> you know this will be unsafe and are willing to take this risk to get the job 
> done. This is opt-in risk.
> 
> Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just 
> have a keyword for “Open” as an access level, and if you subclass or override 
> things that are not “open” from other modules, you must mark unsafe.
> 
> I think this is a decent compromise: We allow potential to patch, but 
> discourage without acknowledgement of the risk. Allow Final and Open to be 
> declarative.
Finally: Someone from the other party who not only speaks about compromise, but 
also shares a compatible way of thinking :-)
All those strict rules are a pointless attempt to trade freedom for security, 
and are purely cosmetic in most cases: In the context of open source, they are 
a blunt sword, whose only power is to annoy users.
Instead of trying to avoid all possible problems users of your library may run 
into, it's better to treat them as adults who know what they are doing — and 
make sure that the actually know what they are doing.

The defaults should match reality, and that is neither "overriding is trouble" 
nor "it's safe to subclass"; it is "I haven't thought about overriding yet".
There is even a natural choice for the syntax to acknowledge that you are aware 
of doing something that might be dangerous: Simply add an exclamation mark to 
override.

Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Colin Cornaby via swift-evolution]

> 
>   * What is your evaluation of the proposal?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Extremely strong -1.

I understand the performance benefit, but it’s extremely problematic if you’ve 
used other languages like C++ that make the same tradeoff. The performance 
benefit also seems unnecessary for a lot of code, and if you need the 
performance, it’s easy enough to mark the class final.

Being able to subclass is critical not only to OOP design, but also Cocoa 
design. Making classes final by default will mean that a lot of classes will 
unnecessarily not support subclassing, which can complicate design.

This also strongly affects unit testing by getting rid of one of the easiest 
ways to mock input and output to a unit. It’s not enough to say third party 
code should be treated as black box. One of the best ways to test input and 
output from an object is to subclass the objects it communicates to and 
override the entry points. The biggest gaps I have in my code coverage are 
where I talk to non-virtual-by-default C++ methods and I can’t mock the output 
from those modules to hit all my cases.

As someone who writes an API for my day job, I am perfectly fine marking things 
as final by hand when necessary (when I finally get to jump to Swift.) It’s not 
inconvenient at all. I would much rather favor making public inheritance issues 
easier to surface in Swift. Public inheritance can be tricky, but this feels a 
bit like cutting off our noses to spite our own face. If you are a responsible 
public API vendor, you should be thinking about inheritance, or marking as 
final. And it’s wiping out one of Swift and Obj-C’s major advantages over C++.

The “final should be default because adding final after the fact is 
destructive” arguments are interesting, but ultimately not convincing to me. If 
you thought your class was safe for subclassing, but it ultimately wasn’t, this 
solves nothing. You’ll mark your class as subclassable, and you will ship it, 
and there will be issues, but it will still be too late to take things back. If 
you know your class is not safe for subclassing, you should mark it as final. 
There is no advantage here in that scenario.

This is all part of building a safe public API. Public API design can be 
difficult, but if you don’t understand safe subclassing designs, you are likely 
to miss the issues and mark your class as subclassable and ship it anyway. 
Again, the best way to tackle this is to find better ways to surface the 
issues. Making final the default still doesn’t solve the core issues of people 
not understanding the right design.

(I’d, ironically enough, be a lot more open to this proposal if Swift supported 
more dynamic things like proxies that could let you emulate subclassing without 
actually doing so. But I think that’s veering away from relatability of the 
language)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Is it more unreasonable to ask developers to seal their modules or users to 
unseal them? I would say Apple or third parties shipping frameworks could be 
asked to think about subclass ability before shipping their commercial library.

Sent from my iPhone

> On 11 Jul 2016, at 07:36, Rod Brown via swift-evolution 
>  wrote:
> 
> Resent for Swift Evolution:
> 
> With the existence of Swift on the server, dynamically linked, independently 
> distributed frameworks will not be an Apple-only issue - this extends beyond 
> Apple's OS X-based platforms towards how dynamic frameworks link against each 
> other as if they are to be distributed separately.
> 
> It is short sighted to suggest that all Swift deployments will be under 
> Apple's control.
> 
> On 11 Jul. 2016, at 3:43 pm, Tino Heth <2...@gmx.de> wrote:
> 
>>> It is *not* the case with a framework. Dynamically linked frameworks can be 
>>> changed without the app even being changed. Imagine if Apple changed UIKit 
>>> and make UINavigationController final retroactively. 
>> Your argument is true, and you choose a good example — but it's actually the 
>> only one that exists at all:
>> There are no other parties that ship frameworks that way, and I don't think 
>> this should change.
>> 
>> So the benefits of this proposal would exist for Apple alone, and I can 
>> understand why sealed is convenient for an UIKit-engineer.
>> It is tempting to aim for the easiest solution, but it is smarter to take 
>> the route that's better for the customer (and we happen to be the customers).
>> And, as others pointed out before, Cupertino is free to diverge from the 
>> defaults in either direction, so it is only a little effort to have "sealed 
>> by default" without the bad side effects.
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

Resent for Swift Evolution:

With the existence of Swift on the server, dynamically linked, independently 
distributed frameworks will not be an Apple-only issue - this extends beyond 
Apple's OS X-based platforms towards how dynamic frameworks link against each 
other as if they are to be distributed separately.

It is short sighted to suggest that all Swift deployments will be under Apple's 
control.

On 11 Jul. 2016, at 3:43 pm, Tino Heth <2...@gmx.de> wrote:

>> It is *not* the case with a framework. Dynamically linked frameworks can be 
>> changed without the app even being changed. Imagine if Apple changed UIKit 
>> and make UINavigationController final retroactively. 
> Your argument is true, and you choose a good example — but it's actually the 
> only one that exists at all:
> There are no other parties that ship frameworks that way, and I don't think 
> this should change.
> 
> So the benefits of this proposal would exist for Apple alone, and I can 
> understand why sealed is convenient for an UIKit-engineer.
> It is tempting to aim for the easiest solution, but it is smarter to take the 
> route that's better for the customer (and we happen to be the customers).
> And, as others pointed out before, Cupertino is free to diverge from the 
> defaults in either direction, so it is only a little effort to have "sealed 
> by default" without the bad side effects.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> It is *not* the case with a framework. Dynamically linked frameworks can be 
> changed without the app even being changed. Imagine if Apple changed UIKit 
> and make UINavigationController final retroactively. 
Your argument is true, and you choose a good example — but it's actually the 
only one that exists at all:
There are no other parties that ship frameworks that way, and I don't think 
this should change.

So the benefits of this proposal would exist for Apple alone, and I can 
understand why sealed is convenient for an UIKit-engineer.
It is tempting to aim for the easiest solution, but it is smarter to take the 
route that's better for the customer (and we happen to be the customers).
And, as others pointed out before, Cupertino is free to diverge from the 
defaults in either direction, so it is only a little effort to have "sealed by 
default" without the bad side effects.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
> 
> It is pre-breaking in that it is the exact same code that doesn’t work in 
> both cases (only in the pre-breaking case, a bunch of other code also doesn’t 
> work).  I know it feels different because it “was never possible” vs our 
> change being the cause, but it is one of those things like me giving you $5 
> or giving you $10 and later taking back $5.  As humans we are loss averse so 
> we devise strategies to hide the loss from ourselves.

I completely disagree with this.

 Not providing someone something due to risk of breakage is not the same thing 
as “giving it and taking it away”. We don’t build bridges out of spare parts 
and tell people “We build it but we expect it to break at some stage, so use 
with caution.” You either build it correctly, or you don’t let people cross the 
bridge. At All.

This isn’t about “loss averse”. This is about risk management.

Where does the line lie on risk? That’s ultimately something the core team will 
have to decide.




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jonathan Hull via swift-evolution]

> On Jul 10, 2016, at 6:45 PM, Rod Brown  wrote:
> 
> @Jonathan
> 
> I don’t think that "pre-breaking code" is a good description. You are not 
> breaking anything - you’re just not allowing something that *could* become 
> unsafe. It’s safety first, at the cost of the library user’s flexibility.

It is pre-breaking in that it is the exact same code that doesn’t work in both 
cases (only in the pre-breaking case, a bunch of other code also doesn’t work). 
 I know it feels different because it “was never possible” vs our change being 
the cause, but it is one of those things like me giving you $5 or giving you 
$10 and later taking back $5.  As humans we are loss averse so we devise 
strategies to hide the loss from ourselves.


> That said, I actually think you have a good point however that “sealed” 
> should be able to be overridden, either in a patch capacity or an “unsafe” 
> capacity. Should this become final at a later point, you have acknowledged 
> you know this will be unsafe and are willing to take this risk to get the job 
> done. This is opt-in risk.
> 
> Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just 
> have a keyword for “Open” as an access level, and if you subclass or override 
> things that are not “open” from other modules, you must mark unsafe.
> 
> I think this is a decent compromise: We allow potential to patch, but 
> discourage without acknowledgement of the risk. Allow Final and Open to be 
> declarative.

Pretty much, but it is important IMHO to separate this from access levels.  
They need to be orthogonal concepts or it will be confusing (e.g. why are 
structs “public” but classes “open”?).  

The default in that case would actually be ‘sealed internal(open)’ which would 
suck to type repeatedly, but you won’t have to because it is the default.  The 
thing you would type often would be ‘public open’, which is shorter than the 
new keywords in the proposal (and consistent for both classes and methods 
instead of learning different words)

I think we basically agree overall.

Thanks,
Jon


> 
> - Rod
> 
> 
> 
>> On 11 Jul 2016, at 11:05 AM, Jonathan Hull > > wrote:
>> 
>> @Rod:  Thank you for actually replying to the content of my post.  Much 
>> appreciated.
>> 
>> It is a trolly problem.  You are arguing that pre-breaking everyone's code 
>> is better (even if causes way more trouble overall) than taking an action 
>> that breaks a few people’s code later (and thus feeling responsible).  There 
>> are other options. I grew up watching enough Star Trek that I don’t believe 
>> in no win scenarios.
>> 
>> I still think my compromise is the best solution.  3 levels: Open, Sealed, 
>> Final.  The difference is that sealed can be overridden with a compiler 
>> warning and use of “unsafe” keyword, but final can’t be overridden.  That 
>> way the user is acknowledging that they are doing something which isn’t 
>> supported in the context which they are doing it… but it doesn’t completely 
>> prevent it by default.  Opt-out safety.  (Yes you lose some compiler 
>> optimizations in the default case, but that was premature optimization 
>> anyway).
>> 
>> As for the interaction with public/internal/etc… that should be explicit.  
>> This proposal confuses and intermingles them.  You should just be able to 
>> say ‘public final internal(open)’ or some other syntax which lets you 
>> express the same sentiment.  (The above says the class/method is public and 
>> final, but internally it is open.)
>> 
>> I am not saying that we shouldn’t solve these issues.  I am saying this 
>> proposal:
>> 1) Isn’t easily discoverable.
>> 2) Requires communication between different parties (author and user) which 
>> slows iteration cycles to weeks or months (vs the usual minutes)
>> 3) Conflates/mixes the ideas of access level and subclass-ability
>> 4) Makes way too many separate changes in a single proposal: New idea of 
>> “sealed”, new default, replaces ‘public’ in some cases but not others, new 
>> keywords (which everyone wants to change), etc…
>> 5) Has structural problems which mean that it won’t actually increase 
>> thoughtfulness
>> 6) Makes app developers extremely dependent on framework authors (and those 
>> author’s schedules)
>> 7) Will require us to patch/fix it later, but that will be difficult due to 
>> optimizations/assumptions of finality.
>> 8) Will cause unnecessary pain for both framework authors and users of 
>> frameworks
>> 
>> We would be foolish to accept this proposal without planning for the 
>> inevitable escape hatch.  We will need it, and if we don’t plan for it, it 
>> will break everything when we are forced to fix it in Swift 4/5.  Anything 
>> else is idealistic to the point of ignoring real-world use/behavior.
>> 
>> As I said before, this type of thinking: “If we just make things more 
>> difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
>> Java. 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

@Jonathan

I don’t think that "pre-breaking code" is a good description. You are not 
breaking anything - you’re just not allowing something that *could* become 
unsafe. It’s safety first, at the cost of the library user’s flexibility.

That said, I actually think you have a good point however that “sealed” should 
be able to be overridden, either in a patch capacity or an “unsafe” capacity. 
Should this become final at a later point, you have acknowledged you know this 
will be unsafe and are willing to take this risk to get the job done. This is 
opt-in risk.

Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just have 
a keyword for “Open” as an access level, and if you subclass or override things 
that are not “open” from other modules, you must mark unsafe.

I think this is a decent compromise: We allow potential to patch, but 
discourage without acknowledgement of the risk. Allow Final and Open to be 
declarative.

- Rod



> On 11 Jul 2016, at 11:05 AM, Jonathan Hull  wrote:
> 
> @Rod:  Thank you for actually replying to the content of my post.  Much 
> appreciated.
> 
> It is a trolly problem.  You are arguing that pre-breaking everyone's code is 
> better (even if causes way more trouble overall) than taking an action that 
> breaks a few people’s code later (and thus feeling responsible).  There are 
> other options. I grew up watching enough Star Trek that I don’t believe in no 
> win scenarios.
> 
> I still think my compromise is the best solution.  3 levels: Open, Sealed, 
> Final.  The difference is that sealed can be overridden with a compiler 
> warning and use of “unsafe” keyword, but final can’t be overridden.  That way 
> the user is acknowledging that they are doing something which isn’t supported 
> in the context which they are doing it… but it doesn’t completely prevent it 
> by default.  Opt-out safety.  (Yes you lose some compiler optimizations in 
> the default case, but that was premature optimization anyway).
> 
> As for the interaction with public/internal/etc… that should be explicit.  
> This proposal confuses and intermingles them.  You should just be able to say 
> ‘public final internal(open)’ or some other syntax which lets you express the 
> same sentiment.  (The above says the class/method is public and final, but 
> internally it is open.)
> 
> I am not saying that we shouldn’t solve these issues.  I am saying this 
> proposal:
> 1) Isn’t easily discoverable.
> 2) Requires communication between different parties (author and user) which 
> slows iteration cycles to weeks or months (vs the usual minutes)
> 3) Conflates/mixes the ideas of access level and subclass-ability
> 4) Makes way too many separate changes in a single proposal: New idea of 
> “sealed”, new default, replaces ‘public’ in some cases but not others, new 
> keywords (which everyone wants to change), etc…
> 5) Has structural problems which mean that it won’t actually increase 
> thoughtfulness
> 6) Makes app developers extremely dependent on framework authors (and those 
> author’s schedules)
> 7) Will require us to patch/fix it later, but that will be difficult due to 
> optimizations/assumptions of finality.
> 8) Will cause unnecessary pain for both framework authors and users of 
> frameworks
> 
> We would be foolish to accept this proposal without planning for the 
> inevitable escape hatch.  We will need it, and if we don’t plan for it, it 
> will break everything when we are forced to fix it in Swift 4/5.  Anything 
> else is idealistic to the point of ignoring real-world use/behavior.
> 
> As I said before, this type of thinking: “If we just make things more 
> difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
> Java.  The problem is, the brain doesn’t work that way, and it ultimately 
> just adds pain without being effective.  You can add forcing functions (like 
> optional unwrapping), which are annoying, but effective… but as I also 
> mentioned before this proposal doesn’t do that.  It is structurally 
> different.  It will not do what you think it does.
> 
> Thanks,
> Jon
> 
> P.S.  There is also a dangerous difference between helping the programmer 
> catch mistakes (e.g. don’t accidentally subclass the wrong method) and trying 
> to prevent them from coding in a style you disagree with.  I have been seeing 
> far to many proposals of the second variety of late.
> 
> 
>> On Jul 10, 2016, at 2:58 PM, Rod Brown > > wrote:
>> 
>> I personally agree with most of your assessments. It's why I pushed so hard 
>> for "allow subclassing my default" in the first discussion of this point.
>> 
>> The problem with this is simple: you cannot retroactively "close up" an API. 
>> I cannot add final to a class I have previously declared as non-final. I 
>> also can seal a class which has previously been open to subclassing.
>> 
>> Consider: someone builds against my framework and I do 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose via swift-evolution]

>> 
>>> 2016/07/09 23:30、Matthew Johnson >> > のメール：
>>> 
>>> This leaves the scenario of a case where you depend on a 3rd party, 
>>> closed-source library written in Swift and where you cannot get (or use) a 
>>> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
>>> it is not large enough to outweigh all of the advantages of making sealed 
>>> the default.  
>> What are your thoughts on an ability for a way to force unseal a class that 
>> does need to be fixed, even if its temporary?
>> 
>> Something like:
>> 
>> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits 
>> a scary compiler warning
>> }
>> 
>> Does that even seem feasible/possible, much less reasonable…?
>> Though it would have to be a perhaps separate discussion, this comes to my 
>> mind as becoming necessary down the road, but maybe I’m wrong...
> 
> I'm not opposed to something like this in principle, but I'm not sure how it 
> would work in practice.  There was some discussion of something along these 
> lines on the list at one point (I think Joe Groff had some ideas).  However, 
> I don't think this is possible if the optimizer takes advantage of the sealed 
> status when the library is compiled.  I'll leave it to the compiler experts 
> to comment further on feasibility.  

My technical analysis: It’s certainly implementable to have the optimizer not 
take advantage of the sealed status, and to allow some sort of 
“unsafe-break-the-seal” syntax. We’d have to be sure that anything that “can’t 
possibly happen without external subclassing” still at least generates a 
deterministic trap rather than memory corruption, but that’s probably doable.

(I’ll leave it at that, without trying to argue a particular side.)


>> 
>>> I have seen some comments about nontrivial complexity in Apple’s frameworks 
>>> caused by apps subclassing where they should not have (i.e. classes that 
>>> would be sealed if it were possible in Objective-C).  This is extremely 
>>> unfortunate and it impacts everyone on Apple’s platforms.
>>> 
>>> I wish I had links handy for you, but I don’t recall exactly where or when 
>>> this was mentioned and don’t have time to dig them up right now.
>> I see, thats reasonable… if those links are available somewhere I would 
>> definitely like to see them, it would be a good education for me…
> 
> IIRC like Jordan Rose may have made some comments along these lines either on 
> list or on Twitter if you want to search, but that is a fuzzy memory and 
> could easily be wrong.  :)

I don’t have anything handy (partially because some of it isn’t public 
knowledge), but it’s a well-known phenomenon within Apple that new OSs break 
third-party apps in strange ways because they are relying on being able to 
swizzle a non-public selector, or even on its existence. I’ll admit I don’t 
hear as much about intrusive subclassing, but that doesn’t mean Apple hasn’t 
made changes that assume no one subclasses a particular class.

[For anyone who doesn’t know the term “method swizzling”: Objective-C allows 
you to replace a class’s implementation of a method at run-time, regardless of 
where the class or the replacement is defined.]

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

This is the case with a library.

It is *not* the case with a framework. Dynamically linked frameworks can be 
changed without the app even being changed. Imagine if Apple changed UIKit and 
make UINavigationController final retroactively. UIKit internally would 
therefore call directly to the UINavigationController methods statically, and 
bypass any subclass’s methods, thereby breaking applications. Should app apps 
have to be rebuilt to work with iOS 12 simply because Apple shipped a new 
version of UIKit? This is illogical. You will *break* things by finalising 
after the fact. Swift, being about safety, needs to deal with this safely.


> On 11 Jul 2016, at 9:13 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> The problem with this is simple: you cannot retroactively "close up" an API. 
>> I cannot add final to a class I have previously declared as non-final. I 
>> also can seal a class which has previously been open to subclassing.
> Of course you can do both — it may make users angry, but so what?
> The essence of this way of thinking is "I fear the reaction of my users when 
> I take something away from them… so I have to deny them those options right 
> from start".
> 
> I've no statistics (there's a general lack of facts all over the place…), but 
> I don't thing the majority of todays and future libraries are build with a 
> strictly planned top-down approach and guarantees about API-stability. 
> Nowadays things are much more spontaneous, and the strict rules and limits 
> some people here want to force upon others would most likely decrease the joy 
> in playing with the language and start experiments in it.
> 
> There is only a very small number of Swift-developers writing frameworks that 
> are used on a large scale basis, and even if many people in this group vote 
> for limiting defaults, the focus should be on the majority:
> When I come to the conclusion that a set of classes in a project could be 
> useful somewhere else, my problem is not fear of future API changes — it is 
> the daunting task of having to sprinkle "public" all over the place.
> Sealing classes makes proper code reuse a more tedious job, and I want Swift 
> to stay fun rather than become a playground for sticklers for order.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jonathan Hull via swift-evolution]

@Rod:  Thank you for actually replying to the content of my post.  Much 
appreciated.

It is a trolly problem.  You are arguing that pre-breaking everyone's code is 
better (even if causes way more trouble overall) than taking an action that 
breaks a few people’s code later (and thus feeling responsible).  There are 
other options. I grew up watching enough Star Trek that I don’t believe in no 
win scenarios.

I still think my compromise is the best solution.  3 levels: Open, Sealed, 
Final.  The difference is that sealed can be overridden with a compiler warning 
and use of “unsafe” keyword, but final can’t be overridden.  That way the user 
is acknowledging that they are doing something which isn’t supported in the 
context which they are doing it… but it doesn’t completely prevent it by 
default.  Opt-out safety.  (Yes you lose some compiler optimizations in the 
default case, but that was premature optimization anyway).

As for the interaction with public/internal/etc… that should be explicit.  This 
proposal confuses and intermingles them.  You should just be able to say 
‘public final internal(open)’ or some other syntax which lets you express the 
same sentiment.  (The above says the class/method is public and final, but 
internally it is open.)

I am not saying that we shouldn’t solve these issues.  I am saying this 
proposal:
1) Isn’t easily discoverable.
2) Requires communication between different parties (author and user) which 
slows iteration cycles to weeks or months (vs the usual minutes)
3) Conflates/mixes the ideas of access level and subclass-ability
4) Makes way too many separate changes in a single proposal: New idea of 
“sealed”, new default, replaces ‘public’ in some cases but not others, new 
keywords (which everyone wants to change), etc…
5) Has structural problems which mean that it won’t actually increase 
thoughtfulness
6) Makes app developers extremely dependent on framework authors (and those 
author’s schedules)
7) Will require us to patch/fix it later, but that will be difficult due to 
optimizations/assumptions of finality.
8) Will cause unnecessary pain for both framework authors and users of 
frameworks

We would be foolish to accept this proposal without planning for the inevitable 
escape hatch.  We will need it, and if we don’t plan for it, it will break 
everything when we are forced to fix it in Swift 4/5.  Anything else is 
idealistic to the point of ignoring real-world use/behavior.

As I said before, this type of thinking: “If we just make things more 
difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
Java.  The problem is, the brain doesn’t work that way, and it ultimately just 
adds pain without being effective.  You can add forcing functions (like 
optional unwrapping), which are annoying, but effective… but as I also 
mentioned before this proposal doesn’t do that.  It is structurally different.  
It will not do what you think it does.

Thanks,
Jon

P.S.  There is also a dangerous difference between helping the programmer catch 
mistakes (e.g. don’t accidentally subclass the wrong method) and trying to 
prevent them from coding in a style you disagree with.  I have been seeing far 
to many proposals of the second variety of late.


> On Jul 10, 2016, at 2:58 PM, Rod Brown  wrote:
> 
> I personally agree with most of your assessments. It's why I pushed so hard 
> for "allow subclassing my default" in the first discussion of this point.
> 
> The problem with this is simple: you cannot retroactively "close up" an API. 
> I cannot add final to a class I have previously declared as non-final. I also 
> can seal a class which has previously been open to subclassing.
> 
> Consider: someone builds against my framework and I do nothing, and they 
> subclass my classes. Then later I come through and mark the classes as 
> "Sealed". What should we do with those classes that are subclassing my 
> classes? Nothing. I can't. I permitted access and now I'm beholden to that 
> access level.
> 
> On the other hand, opening up access levels gradually has no such issues. 
> Users of my class can't subclass, and then they can. They just have another 
> tool in the bag now.
> 
> If you want a default, it should be one you can reverse later. Your default 
> should not be the most restrictive.
> 
> Whilst I agree with most of your points, this core concept seems to trump 
> them to my mind.
> 
> - Rod
> 
> On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution 
> > wrote:
> 
>> Please stop saying that this proposal will bring more consideration to the 
>> design of libraries.  It isn’t true.  I haven’t even seen an argument for 
>> why it would be true, it is just taken for granted that it is true.
>> 
>> As I mentioned in another post, this is structurally very different from 
>> things like ‘if-let’ and optionals.  Optionals force the user to consider 
>> their 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> The problem with this is simple: you cannot retroactively "close up" an API. 
> I cannot add final to a class I have previously declared as non-final. I also 
> can seal a class which has previously been open to subclassing.
Of course you can do both — it may make users angry, but so what?
The essence of this way of thinking is "I fear the reaction of my users when I 
take something away from them… so I have to deny them those options right from 
start".

I've no statistics (there's a general lack of facts all over the place…), but I 
don't thing the majority of todays and future libraries are build with a 
strictly planned top-down approach and guarantees about API-stability. Nowadays 
things are much more spontaneous, and the strict rules and limits some people 
here want to force upon others would most likely decrease the joy in playing 
with the language and start experiments in it.

There is only a very small number of Swift-developers writing frameworks that 
are used on a large scale basis, and even if many people in this group vote for 
limiting defaults, the focus should be on the majority:
When I come to the conclusion that a set of classes in a project could be 
useful somewhere else, my problem is not fear of future API changes — it is the 
daunting task of having to sprinkle "public" all over the place.
Sealing classes makes proper code reuse a more tedious job, and I want Swift to 
stay fun rather than become a playground for sticklers for order.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

I personally agree with most of your assessments. It's why I pushed so hard for 
"allow subclassing my default" in the first discussion of this point.

The problem with this is simple: you cannot retroactively "close up" an API. I 
cannot add final to a class I have previously declared as non-final. I also can 
seal a class which has previously been open to subclassing.

Consider: someone builds against my framework and I do nothing, and they 
subclass my classes. Then later I come through and mark the classes as 
"Sealed". What should we do with those classes that are subclassing my classes? 
Nothing. I can't. I permitted access and now I'm beholden to that access level.

On the other hand, opening up access levels gradually has no such issues. Users 
of my class can't subclass, and then they can. They just have another tool in 
the bag now.

If you want a default, it should be one you can reverse later. Your default 
should not be the most restrictive.

Whilst I agree with most of your points, this core concept seems to trump them 
to my mind.

- Rod

> On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Please stop saying that this proposal will bring more consideration to the 
> design of libraries.  It isn’t true.  I haven’t even seen an argument for why 
> it would be true, it is just taken for granted that it is true.
> 
> As I mentioned in another post, this is structurally very different from 
> things like ‘if-let’ and optionals.  Optionals force the user to consider 
> their decision in the context it is being used (i.e. as you use the 
> optional/value).  This proposal, however, does the opposite.  The effect of 
> your actions appear in the context of a completely different user.  It is 
> like sitting in a room, flipping a light switch wondering “I wonder what this 
> does?”… meanwhile the people downstairs are wondering why their lights keep 
> turning off and on”.  
> 
> You can try to test for this, but by definition library authors can only test 
> for scenarios that they have thought of.  I have often found people surprise 
> me with their use-cases.  Relying on the diligence of other programmers is 
> what leads to things like: "You always need to remember to test for zero 
> before using a pointer".  Literally the opposite of optionals!  It sounds 
> good, but at the end of the day, people are human and they WILL make 
> mistakes.  Best to either catch those mistakes in the context where they 
> happen or to mitigate the effect of it.  This proposal basically forces you 
> to feel the full effect of other people's mistakes (thinking that it will 
> discourage them from making them in the first place).
> 
> Your only real mechanism for feedback is when users of your library complain 
> to you that something that they need isn’t subclass-able.  This is the point 
> where most framework authors will actually learn that this feature/default 
> exists.  Users of a framework will learn of it slightly earlier, when they 
> find they need to subclass something, and it just isn’t possible.
> 
> 
> I would much prefer adding a ‘sealed’ keyword which library authors could use 
> to annotate things which they do not want subclassed outside of the module.  
> Or preferably, as others have suggested, allow augmentation of ‘final’ with 
> ‘public(final)' or ‘internal(final)’.
> 
> The only case where I would support ‘sealed’ by default is if there are 3 
> levels: open, sealed, final.  Final would allow 'public(final)' and 
> 'internal(final)’ to allow private subclassing inside the file/module.  
> Sealed would be the same, except it would allow the user to subclass by 
> explicitly acknowledging the risk using ‘unsafe’:  “unsafe class 
> MySubclass:SealedSuper“ and  “unsafe override func”.  Final would not allow 
> the override.
> 
> That is the case where ‘sealed’ makes sense as a default…
> 
> Thanks,
> Jon
> 
> P.S. The current proposal will only cause massive problems down the line, 
> IMHO.  We will find an escape hatch is needed, but we will have made 
> optimizations based on assumptions of finality which prevent us from easily 
> adding one.
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Garth Snyder via swift-evolution]

> Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive 
> example to illustrate that this proposal could actually improve 
> something...even if there are cases which cannot be repelled with the simple 
> advice "just don't subclass", this would only be a basis to start talking 
> about the actual pros and cons.

> Leonardo Pessoa responded: ...an app which will have object representations 
> of Files and Folders (both come from a common class called Entry). You [can] 
> extend from File and Entry freely but...it is important you don't subclass 
> any type of Folder. Without this proposal I would have to create workarounds 
> to prevent you from doing that while still allowing me to subclass while 
> playing a lot of finals everywhere. And so far I would have to allow you to 
> subclass Folder itself (at least) but you would complain (and possibly file a 
> bug report to me) because it would not be working properly because your 
> classes would not benefit from the workaround. In this case, if I could 
> subclass internally but prevent you from doing it, you could complain I'm not 
> allowing you to do whatever you want but you wouldn't complain my code 
> doesn't work properly (it does, you just won't know it).


To me, this scenario seems like an example of why the proposal should be 
rejected.

Correct me if I’m wrong, but your (Leonardo’s) narrative suggests that the 
subclassability of File and Entry is incidental. If the intent was actively to 
allow people to provide their own implementations of filesystem objects, you 
would presumably have taken whatever steps were necessary to make Folder 
subclassable as well.

This scenario ends up defining a perfectly commonplace mix of classes. Some of 
them behave reasonably when subclassed and some don’t. The question is, should 
Swift — as a matter of default policy and community style — actively push you 
to seal ALL of these classes?

No, it shouldn’t. You’d be removing the possibility of functionality that’s 
potentially useful to some clients, without gaining much in return.

A “sealed” keyword or equivalent seems plausible, but it shouldn’t be the 
default. 

Even an affirmative “sealed" feels prone to abuse, however. In this case, for 
example, I would imagine there would be considerable temptation to mark all 
objects (Entry, File, Folder, etc.) as sealed, just because Folder needs it. 
API designers (and clients!) dislike unexplained asymmetry.

Garth

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 10, 2016, at 7:34 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz  wrote:
>> 
>> 
>>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson :
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  wrote:
 
 
 
> Am 08.07.2016 um 15:59 schrieb Matthew Johnson :
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
>> 
>> 
>> 
>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>>> :
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
  wrote:
 
 n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
  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, 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

> Am 10.07.2016 um 19:34 schrieb Matthew Johnson :
> 
> 
> 
> Sent from my iPad
> 
> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz  > wrote:
> 
>> 
>>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson >> >:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz >> > wrote:
>>> 
 
 
 Am 08.07.2016 um 15:59 schrieb Matthew Johnson >:
 
> 
> 
> Sent from my iPad
> 
> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  > wrote:
> 
>> 
>> 
>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>> >:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
 n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
 > 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.
>>> 
>>> 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

> Am 08.07.2016 um 17:24 schrieb Matthew Johnson :
> 
> 
> 
> Sent from my iPad
> 
> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  > wrote:
> 
>> 
>> 
>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz >> > wrote:
>>> 
 
 
 Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
 >:
 
> 
> 
> Sent from my iPad
> 
> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
> > wrote:
> 
>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>> > 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 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

Two days ago, I challenged the supporters of this proposal to show a singe 
persuasive example to illustrate that this proposal could actually improve 
something.
I got a single reply — which did not contain an example, but just the claim 
that there is one…
Imho that alone should be enough to cancel the whole thing, because even if 
there are cases which cannot be repelled with the simple advice "just don't 
subclass", this would only be a basis to start talking about the actual pros 
and cons.

So for me, the promised benefits are less likely than the existence of Bigfoot:
I guess there are at least several hundred people who swore they have seen him, 
and there are even some blurry photos ;-)

Of course, it is impossible to come up with an unquestionable argument for the 
change — and it's also impossible to prove the opposite, because the whole 
debate makes as much sense as arguing wether raisins are tasteful or terrible; 
it's nothing but personal preference, and the only thing we can hope for is 
that the bias of those who will decide this proposal isn't at odds with the 
needs of the majority.

If we can agree that it is not about facts, but about opinion, there are still 
fundamental arguments against SE-0117:
Those who have issues with subclassing can just resign from it (as users of a 
library), and they can annotate their classes to dictate their usage (as an 
author) — but if you think subclassing is still a good tool, you can't do 
anything with a sealed class.
Additionally, please note that those who ask for stricter rules and more 
regulation have many reasons to be happy with the status quo:
You can subclass neither structs nor enums, and by default, you can't inherit 
from a framework-class as well, because it is internal — and yet they yell for 
more.

Swift claims to be opinionated, not to aim for compromise — but if plain old OO 
isn't compatible with the ideals of the language, it would be more honest to 
just completely remove inheritance instead of slowly crippling it's 
possibilities.

- Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

This has been a very interesting and educational thread.
Thanks to everyone who kindly replied to me and explained things.

Here is my 2¢…

>  * What is your evaluation of the proposal?
+0 as it stands… 
+1 if there could be a reliable way for us to explicitly un-seal a sealed class 
for those times where its absolutely necessary.

If its at all feasible… maybe something like ...


public class MyWorkaroundClass : @forceOpen(YourSealedClass) {  //Obligatory 
Compiler Warning Occurs
public override func @forceOpen(brokenFunc()) {/*FIXME*/}
}
(The above is just a rough idea, please don't yell at me for the ugliness... )

Just like we have forced unwrapping of optionals (for only when we really need 
it), I believe that we should be able to force unseal when we truly need it;

Another +1 if the keyword is changed from subclassable/overridable to something 
less confusing… since people might be easily be misled and think that even 
within thier own module if they don't mark it subclassable it won’t be 
subclassable… perhaps "open" is the better keyword…

public open class MyOpenClass {  
public open func openFunc() {/*OVERRIDE ME!*/}
}
In this case, "open" can only apply to public classes/methods/accessors, 
anything else using "open" ("private open" etc) will be an obvious error.

Please note that I am not against this proposal in theory; only that I would 
humbly request that the two items above be at least considered and I will 
happily jump on board.

>  * Is the problem being addressed significant enough to warrant a change to 
> Swift?
I do think it is, because the potential upsides are many, such as better 
fencing between modules and users of those modules, potential performance gains 
and making it more explicit to a library writer what he/she is going to make 
public and also modifiable by consumers of the provided API.

Again though, I would be reticent to agree 100% if there werent a way to punch 
though that fence when we need to, not allowing such a thing makes the 
environment too rigid/unproductive and thats not the Swift I want to continue 
using. Swift is not C++ minus the C… is it?

>  * Does this proposal fit well with the feel and direction of Swift?
I think overall it does because swift encourages more ad-hoc composition than 
inheritance based, so making inheritability more explicit does seem to fit in 
with the direction of Swift… although the lack of ability to escape that 
limitation just like we have with forced unwrapped optionals makes me feel its 
at the same time not fully in line with the direction of swift… hence the +0 
instead of a full +1.

>  * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
Someone here brought up Kotlin, but I have only dabbled with it.. It seems 
similar to that from what I can read… but I have no experience with writing or 
consuming a library in Kotlin.

>  * How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

I have been wrestling with this in my mind since late last year when it first 
appeared on the swift-evolution list as a general discussion. 
I was originally very very strongly -1 on this (especially coming from an 
Objective-C background), but after reading the proposal and everyones replies 
both for and against, and thinking again deeply about my own code, have come 
around to believe that there are potential gains for this that are worthwhile, 
but only if some flexibility remains in the language to work around classes 
that are both closed-source and has a defect that is needed to workaround 
though subclassing.
——

Pros
Better Fencing Between Modules
Potential Performance Gains
Subclassing is Discouraged Unless its Explicitly Thought About

Cons
Unable to Override a Method/Accessor on a Class that Needs Fixing but is Closed 
Source 
You are at the total mercy of the framework author… (this one is pretty big to 
be honest)


"Unknowns" that make it hard to judge...

What effect this will really have on the community… 
What true objective performance benefits we can expect from inter-module 
optimization…
Will this really make libraries any better?


——

Other thoughts...
While it can be said that because most libraries are open source, the need to 
subclass is lower now than ever -we can just go in and fix something and send a 
pull request-  those of us trapped in large corporations that have (usually 
poorly supported) SDKs shoved down our throats by the suits need a certain 
level of flexibility to work arounds things… 

In debating to support this or not, I am reminded of comments by many here: 
http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/

——


Thanks,

Andre


> 2016/07/06 8:11、Chris Lattner via swift-evolution  
> のメール：
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jul 10, 2016, at 12:01 AM, Károly Lőrentey via swift-evolution 
 wrote:

>> On 2016. Jul 9., at 22:55, Goffredo Marocchi  wrote:
>> 
>> Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have 
>> the current setup by default? Why C++ x09/x11/x14 is also not making 
>> everything sealed/unsubclassable by default?
> 
> I'd wager a guess that the strong desire not to break source compatibility 
> with existing code explains why Java and C++ are stuck forever with 
> suboptimal defaults.

May I suggest that you might want to read about it if you have any interest in 
making accurate statements about it.

> Some members of this list have a bit of background in C++ language design 
> (understatement of the day!); perhaps they know more.
> 
>> Is it possible that having library authors use something like a sealed 
>> keyword or similar is good enough for the default case?
> 
> Swift is to be safe by default. I believe open subclassability is a power 
> tool that's unsafe without adequate training and thick protective gear; 
> therefore, it is useful to require posting yellow/black hazard signs when it 
> is in use. Safety first.
> 
> "Opting for safety sometimes means Swift will feel strict, but we believe 
> that clarity saves time in the long run."

It each their own... some people like the mental comfort of others building 
safeguard for them, others like to live baring the full weight of the 
consequences of their choices. Nothing wrong, just two different approaches to 
life.


> 
> Karoly
> @lorentey
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

> Am 06.07.2016 um 13:39 schrieb Matthew Johnson via swift-evolution 
> :
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> Huge +1.
>> 
>> Question about inheritance though:
>> 
>> class A {} // Not publicly subclassable 
>> subclassable class B: A {} // Publicly subclassable
>> class C: B {} // Not publicly subclassable? Or is the subclassability 
>> inherited?
> 
> This is a great question.  There are really two questions: 
> 
> Can B be marked "subclassable" even though its superclass isn't?  Allowing 
> this allows creation of new classes with A as an ancestor.  Since this is 
> explicitly opt-in all within the same module I'm inclined to say we should 
> allow it.  
> 
> Is subclassability inherited by in-module subclasses?  This seems to me 
> opposed to the spirit of closed by default.  I think it is better to require 
> annotation on *every* class an method that is open to extension outside the 
> module, regardless of what choice a superclass makes,
> 
> This gives module authors the most control over *exactly* which classes can 
> be used as superclasses outside the module (A and C don't need to be 
> subclassable just because B needs to be.

I totally agree with both points.

-Thorsten 


> 
> -Matthew
> 
>> 
>> I'm not a big fan of the subclassable keyword either since it's quite long, 
>> not to mention it contains "class" which is the next keyword, making it 
>> visually repetitive.
>> 
>> I'd prefer open on both class and func to introduce only one keyword instead 
>> of two and possibly make it as a modifier of public to keep it in line with 
>> private(set)...
>> 
>>> On Jul 6, 2016, at 1:11 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Also "subclassable class" sounds a bit redundant. In other words, I think 
> subclassable implies it is a class.
That's a good point:
There is no inherent reason that you can't inherit from a struct, and that 
might be possible in a future version of swift.
"subclassable struct MyValue" doesn't read that bad, but depending on how much 
emphasis is given to the difference of classes and structs, this could be 
irritating.

But imho the naming is bad anyways:
Both keywords are completely irrelevant for "regular" developers, yet they are 
directly linked to fundamental concepts of the language.
Removing "overridable" from a method has not the expected effect (you still can 
override it), and the same is true for subclassable.
Something abstract (like "virtual") would be a little less confusing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey via swift-evolution]

On 2016-07-09 22:01:38 +, Károly Lőrentey via swift-evolution said:



On 2016. Jul 9., at 22:55, Goffredo Marocchi  wrote:

Why have they not "fixed" this issue with Java 6/7/8 if it is bad to 
have the current setup by default? Why C++ x09/x11/x14 is also not 
making everything sealed/unsubclassable by default?


I'd wager a guess that the strong desire not to break source 
compatibility with existing code explains why Java and C++ are stuck 
forever with suboptimal defaults. Some members of this list have a bit 
of background in C++ language design (understatement of the day!); 
perhaps they know more.


Quick P.S.: I just remembered that JetBrains' Kotlin exists, and it 
made final classes the default:


"By default, all classes in Kotlin are final, which corresponds to 
Effective Java, Item 17: ‘Design and document for inheritance or else 
prohibit it’."

-- https://kotlinlang.org/docs/reference/classes.html#inheritance

They even quote the same authority as I did! <3

It seems to have worked out fine in practice, except for some bad 
interactions with some standard Java packages -- which I do not expect 
to be an issue in our case.


--
Károly
@lorentey


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ricardo Parada via swift-evolution]

I have been following the discussion and reading the arguments in favor and 
against. I think I understand both sides better now. 

If this proposal is accepted I hope some more thought is given to the naming. 

I would like to echo what others have said regarding the names. In particular I 
am still not sure about subclassable and overridable implying public. I think 
it would be more clear to to read "public subclassable class C". 

I have these thoughts regarding the naming:

I think that subclassable could be implied when the class contains an 
overridable method or property. In other words, does it make sense to have an 
overridable method or property when the class is not subclassable? Oh, I just 
realized that it is more clear if it is expressed explicitly. It could also 
avoid making the mistake of making a class subclassable by accident. 

Also "subclassable class" sounds a bit redundant. In other words, I think 
subclassable implies it is a class. But I am not sure I would want to leave out 
the class part, which brings me to one of the other alternatives:

public open class C
public open func / var

The pros here are that is is more concise. The public part could be left out 
because open seems to imply public. Open also suggests that it may be 
subclassable/ overridable. On the other hand subclassable/ overridable are both 
very clear though. 

Thanks


> On Jul 9, 2016, at 12:29 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
>> 
>> 
>>> Of course it can be done either way.  But there are significant ecosystem 
>>> robustness advantages to making sealed the default and comparatively few 
>>> downsides.  Most libraries are open source (so can be modified directly or 
>>> via PR if necessary)
>> First:
>> The claim about robustness sounds like a fact, despite being just an opinion 
>> (feel free to correct me if you have any evidence at all). We should stay 
>> honest with our predictions.
>> Second:
>> Do you really believe there will be positive impact on open-source libraries?
>> My forecast is that closed by default will dramatically increase trivial 
>> pull request where developers ask for unsealing so that they can do as they 
>> like…
> 
> I think this is a good thing.  It will force a considered answer and a 
> discussion about whether or not subclassing should be supported by the 
> library.  
> 
>> and I've no idea why somebody could come up with the idea that forking is 
>> desirable.
> 
> Forking is desirable if your goals, needs, values, etc are substantially 
> different than the library author such that you do not agree on what the API 
> contract should look like.
> 
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Reposting Károl reply on this list.

On Sat, Jul 9, 2016 at 11:01 PM, Károly Lőrentey  wrote:

>
> > On 2016. Jul 9., at 22:55, Goffredo Marocchi  wrote:
> >
> > Why have they not "fixed" this issue with Java 6/7/8 if it is bad to
> have the current setup by default? Why C++ x09/x11/x14 is also not making
> everything sealed/unsubclassable by default?
>
> I'd wager a guess that the strong desire not to break source compatibility
> with existing code explains why Java and C++ are stuck forever with
> suboptimal defaults. Some members of this list have a bit of background in
> C++ language design (understatement of the day!); perhaps they know more.
>
> > Is it possible that having library authors use something like a sealed
> keyword or similar is good enough for the default case?
>
> Swift is to be safe by default. I believe open subclassability is a power
> tool that's unsafe without adequate training and thick protective gear;
> therefore, it is useful to require posting yellow/black hazard signs when
> it is in use. Safety first.
>
> "Opting for safety sometimes means Swift will feel strict, but we believe
> that clarity saves time in the long run."
>
> Karoly
> @lorentey
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey via swift-evolution]

> On 2016. Jul 9., at 22:55, Goffredo Marocchi  wrote:
> 
> Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have the 
> current setup by default? Why C++ x09/x11/x14 is also not making everything 
> sealed/unsubclassable by default?

I'd wager a guess that the strong desire not to break source compatibility with 
existing code explains why Java and C++ are stuck forever with suboptimal 
defaults. Some members of this list have a bit of background in C++ language 
design (understatement of the day!); perhaps they know more.

> Is it possible that having library authors use something like a sealed 
> keyword or similar is good enough for the default case?

Swift is to be safe by default. I believe open subclassability is a power tool 
that's unsafe without adequate training and thick protective gear; therefore, 
it is useful to require posting yellow/black hazard signs when it is in use. 
Safety first.

"Opting for safety sometimes means Swift will feel strict, but we believe that 
clarity saves time in the long run."

Karoly
@lorentey
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey via swift-evolution]

> On 2016. Jul 9., at 18:04, Tino Heth via swift-evolution 
>  wrote:
>> Of course it can be done either way.  But there are significant ecosystem 
>> robustness advantages to making sealed the default and comparatively few 
>> downsides.  Most libraries are open source (so can be modified directly or 
>> via PR if necessary)
> First:
> The claim about robustness sounds like a fact, despite being just an opinion 
> (feel free to correct me if you have any evidence at all). We should stay 
> honest with our predictions.

It has been standard advice in the Java community for at least 15 years to 
always prohibit external subclassing unless the class has been designed and 
documented to be safely subclassable, precisely because of the numerous 
problems that are caused by unforeseen subclassing.

> Second:
> Do you really believe there will be positive impact on open-source libraries?
> My forecast is that closed by default will dramatically increase trivial pull 
> request where developers ask for unsealing so that they can do as they like… 
> and I've no idea why somebody could come up with the idea that forking is 
> desirable.

I may be unusually careful in my API design, but I don't see how opening a 
class to inheritance could ever be a trivial pull request. 

Enabling open subclassing involves the creation of customization hooks: a 
formal list of methods that subclasses are allowed to override to modify the 
behavior of the superclass. These methods need to be designed and their 
override requirements precisely documented. 

Inheritance breaks encapsulation, making the API contract a lot more 
complicated to describe, understand and verify. The public API becomes tainted 
with implementation details that were previously private: for example, the 
exact sequence of overridable methods called by each public function becomes de 
facto part of the public interface. Adding/reordering/removing calls to 
overridable methods can (and, if your package is popular and/or unlucky enough, 
will) break your clients.

Trying to write unit tests to verify a subclassing interface is an exercise in 
frustration; but unless you have adequate coverage, you can't really expect 
package maintainers not to accidentally break the subclassing contract in any 
future release.

Subclassing is an important tool in Swift's toolbox, but it takes considerable 
effort to prepare a class for inheritance. It is not OK to just slap on an 
"open" keyword and call it done; and it is unsafe to let it happen purely by 
accident.

Karoly
@lorentey
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 9, 2016, at 7:06 PM, Jean-Daniel Dupas  wrote:
> 
> 
>> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution 
>>  a écrit :
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jul 9, 2016, at 8:39 AM, Andre  wrote:
 
 Personally, Im not against sealed by default, but I think there are cases 
 where closed source libraries have certain cases where workarounds are 
 necessary, and just sealing by default will prevent those cases. 
 
 One could say, "well just use an open source one, or change vendors" but 
 its not that easy in The Real World™ where we get certain SDKs shoved down 
 our throats by the suits… and while that may be a separate issue to the 
 one at hand, its still a problem that won’t resolve itself by simply 
 locking down things…
 
 In my own case, Ive fought with NSBrowser / NSTreeController in the past 
 and the only way to resolve things was to subclass (and no, waiting 1 or 2 
 years for a fix is not acceptable if you already have a product in the 
 wild).
 
 So I am reticent to support this proposal without an escape hatch for 
 those cases…
>>> 
>>> Are you concerned about closed-source vendor frameworks beyond Apple’s?  
>>> Some things to consider:
>>> 
>>> 1. This proposal should not impact any existing libraries - nobody should 
>>> be shipping closed-source binary libraries written in Swift yet.
>>> 
>>> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
>>> come.  If / when they are replaced with Swift frameworks the default will 
>>> have little (if any) impact on the public API contract.  It is reasonable 
>>> to expect that Apple will review the public contracts carefully and add any 
>>> annotations necessary to achieve the desired semantics.
>>> 
>>> 3. In the future, if you depend on any 3rd party closed-source libraries 
>>> written in Swift you will be able to ship an update to your app that 
>>> contains an updated / fixed version of the library independent of the user 
>>> upgrading their OS.
>>> 
>>> This leaves the scenario of a case where you depend on a 3rd party, 
>>> closed-source library written in Swift and where you cannot get (or use) a 
>>> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
>>> it is not large enough to outweigh all of the advantages of making sealed 
>>> the default.  
>>> 
>>> There is no doubt that adopting sealed by default will place some pressure 
>>> on the Swift ecosystem.  As others have noted, this pressure already exists 
>>> in the form of value types, protocol-oriented designs, etc - the current 
>>> proposal is a relatively modest increase in that pressure.   I believe the 
>>> pressure will have a very positive impact over time (the eventual outcome 
>>> remains to be seen of course).  
>>> 
>>> Swift library vendors will need to choose between opening their source, 
>>> providing responsive support and bug fixes, explicitly providing the escape 
>>> hatch you mention (by designing with open types) or getting a bad 
>>> reputation among users.
>> 
>> There are IMO no advantages to sealing by default. If there were, I cannot 
>> imagine how they can have so consistently eluded the designers and 
>> maintainers of so many great OOD languages in the last 30 years. Does it 
>> mean it is just a matter of time for the core team to take it the c++ 
>> standardization committee to make sure C++ gets enhanced the same way?
> 
> You can’t compare Swift to C++ here. C++ uses « final » method and static 
> dispatch by default, so subclassing does not imply the same fragility than 
> with a fully dynamic language.

... and whole module optimization does final inferrance on anything internal... 
so how much more training wheels do we need to write decent code?  After 30 
years of Objc's msg dispatching being touted as not a performance problem, all 
we hear for the last couple WWDC (did you pay attention to the 'they are 
getting it' during one of the session) is how much every single dynamic 
dispatch must be chased out of our systems, culminating with this 'seal by 
default is best for you'.  Why can't developers writting code be made 
responsible for writing well or not?


> 
> 
>>> 
>>> -Matthew
>>> 
 
 Andre
 
> 2016/07/09 22:11、Shawn Erickson  のメール：
> 
> What I don't get in the arguments against this capability is the fact 
> that many constructs in Swift can't be subclassed. Are we going to 
> prevent library developers from presenting those in the public API? Your 
> ability to subclass things when not supported by the library developer is 
> already going to be greatly reduced. Additionally you are going to miss 
> potentially 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jonathan Hull via swift-evolution]

Please stop saying that this proposal will bring more consideration to the 
design of libraries.  It isn’t true.  I haven’t even seen an argument for why 
it would be true, it is just taken for granted that it is true.

As I mentioned in another post, this is structurally very different from things 
like ‘if-let’ and optionals.  Optionals force the user to consider their 
decision in the context it is being used (i.e. as you use the optional/value).  
This proposal, however, does the opposite.  The effect of your actions appear 
in the context of a completely different user.  It is like sitting in a room, 
flipping a light switch wondering “I wonder what this does?”… meanwhile the 
people downstairs are wondering why their lights keep turning off and on”.  

You can try to test for this, but by definition library authors can only test 
for scenarios that they have thought of.  I have often found people surprise me 
with their use-cases.  Relying on the diligence of other programmers is what 
leads to things like: "You always need to remember to test for zero before 
using a pointer".  Literally the opposite of optionals!  It sounds good, but at 
the end of the day, people are human and they WILL make mistakes.  Best to 
either catch those mistakes in the context where they happen or to mitigate the 
effect of it.  This proposal basically forces you to feel the full effect of 
other people's mistakes (thinking that it will discourage them from making them 
in the first place).

Your only real mechanism for feedback is when users of your library complain to 
you that something that they need isn’t subclass-able.  This is the point where 
most framework authors will actually learn that this feature/default exists.  
Users of a framework will learn of it slightly earlier, when they find they 
need to subclass something, and it just isn’t possible.


I would much prefer adding a ‘sealed’ keyword which library authors could use 
to annotate things which they do not want subclassed outside of the module.  Or 
preferably, as others have suggested, allow augmentation of ‘final’ with 
‘public(final)' or ‘internal(final)’.

The only case where I would support ‘sealed’ by default is if there are 3 
levels: open, sealed, final.  Final would allow 'public(final)' and 
'internal(final)’ to allow private subclassing inside the file/module.  Sealed 
would be the same, except it would allow the user to subclass by explicitly 
acknowledging the risk using ‘unsafe’:  “unsafe class MySubclass:SealedSuper“ 
and  “unsafe override func”.  Final would not allow the override.

That is the case where ‘sealed’ makes sense as a default…

Thanks,
Jon

P.S. The current proposal will only cause massive problems down the line, IMHO. 
 We will find an escape hatch is needed, but we will have made optimizations 
based on assumptions of finality which prevent us from easily adding one.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution 
>  wrote:
> 
> 
>> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
 On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution 
  wrote:
 
 On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
 
 Second:
 Do you really believe there will be positive impact on open-source 
 libraries?
 My forecast is that closed by default will dramatically increase trivial 
 pull request where developers ask for unsealing so that they can do as 
 they like…
>>> 
>>> I think this is a good thing.  It will force a considered answer and a 
>>> discussion about whether or not subclassing should be supported by the 
>>> library.
>> 
>> So, let's say I ask you to support subclassing in your library, and you say 
>> no. What's to stop from just writing something like this:
>> class YesICan {
>>   var foo: YouCantInheritThis
>>   // Duplicate `YouCantInheritThis`'s public API by just passing everything 
>> through to `foo`
>> }
>> 
>> And overloading/extending anything else I need for `YesICan` to, 
>> functionally speaking, inherit from `YouCantInheritThis`.
> 
> You can certainly do this, but it isn’t equivalent to subclassing for at 
> least two reasons.
> 
> First, calls within the methods of YouCantInheritThis will not call into the 
> methods in YesICan. In other words if YouCantInheritThis has both doWork() 
> and okIWill() methods and doWork() calls okIWill(), it will only ever call 
> the implementation of okIWill() in YouCantInheritThis, not the implementation 
> in YesICan. This actually gets to the heart of what one hopes to achieve 
> through final or sealed, specifically avoiding a subclass from inadvertently 
> changing the behavior of a superclass and assumptions the superclass is 
> making about behavior of calls *within that superclass*.
> 
> Second, you cannot pass a YesICan where you can pass a YouCantInheritThis, so 
> if you have another library that traffics in YouCantInheritThises, your 
> “subclass” cannot be used with it.
>  
What if created a protocol 

YouCantInheritThisCloneProtocol{
// everything in sealed class
}

Then you extended the sealed class to conform to the clone protocol. 

Changed the other API that you have source to take a Clone Protocol derived 
object. 

This is getting out of hand :) but I think we need a middle ground somewhere. 





> Mark
> 
>> 
>> Yes, I know it'd all be the epitome of annoying boilerplate code, but my 
>> point is that if someone wants to subclass something of yours, there's 
>> really not much you can do to stop them.
>> 
>> (Before anyone mentions it, yes, the same trick can be used to get around 
>> `final` and `sealed`, but IIRC the motivations there were to enable certain 
>> compiler optimizations, not to prohibit "unauthorized" inheritance.)
>> 
>> - Dave Sweeris
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Yes, I know it'd all be the epitome of annoying boilerplate code, but my 
> point is that if someone wants to subclass something of yours, there's really 
> not much you can do to stop them.
This would be fine: inheritance bad, composition good ;-)

The problems of this attitude just aren't visible now, because it isn't imposed 
on you.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Mark Lacey via swift-evolution]

> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
>> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
>>> 
>>> Second:
>>> Do you really believe there will be positive impact on open-source 
>>> libraries?
>>> My forecast is that closed by default will dramatically increase trivial 
>>> pull request where developers ask for unsealing so that they can do as they 
>>> like…
>> 
>> I think this is a good thing.  It will force a considered answer and a 
>> discussion about whether or not subclassing should be supported by the 
>> library.
> 
> So, let's say I ask you to support subclassing in your library, and you say 
> no. What's to stop from just writing something like this:
>  class YesICan {
>var foo: YouCantInheritThis
>// Duplicate `YouCantInheritThis`'s public API by just passing everything 
> through to `foo`
>  }
> 
> And overloading/extending anything else I need for `YesICan` to, functionally 
> speaking, inherit from `YouCantInheritThis`.

You can certainly do this, but it isn’t equivalent to subclassing for at least 
two reasons.

First, calls within the methods of YouCantInheritThis will not call into the 
methods in YesICan. In other words if YouCantInheritThis has both doWork() and 
okIWill() methods and doWork() calls okIWill(), it will only ever call the 
implementation of okIWill() in YouCantInheritThis, not the implementation in 
YesICan. This actually gets to the heart of what one hopes to achieve through 
final or sealed, specifically avoiding a subclass from inadvertently changing 
the behavior of a superclass and assumptions the superclass is making about 
behavior of calls *within that superclass*.

Second, you cannot pass a YesICan where you can pass a YouCantInheritThis, so 
if you have another library that traffics in YouCantInheritThises, your 
“subclass” cannot be used with it.

Mark

> 
> Yes, I know it'd all be the epitome of annoying boilerplate code, but my 
> point is that if someone wants to subclass something of yours, there's really 
> not much you can do to stop them.
> 
> (Before anyone mentions it, yes, the same trick can be used to get around 
> `final` and `sealed`, but IIRC the motivations there were to enable certain 
> compiler optimizations, not to prohibit "unauthorized" inheritance.)
> 
> - Dave Sweeris
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
>> 
>> Second:
>> Do you really believe there will be positive impact on open-source libraries?
>> My forecast is that closed by default will dramatically increase trivial 
>> pull request where developers ask for unsealing so that they can do as they 
>> like…
> 
> I think this is a good thing.  It will force a considered answer and a 
> discussion about whether or not subclassing should be supported by the 
> library.

So, let's say I ask you to support subclassing in your library, and you say no. 
What's to stop from just writing something like this:
  class YesICan {
var foo: YouCantInheritThis
// Duplicate `YouCantInheritThis`'s public API by just passing everything 
through to `foo`
  }

And overloading/extending anything else I need for `YesICan` to, functionally 
speaking, inherit from `YouCantInheritThis`.

Yes, I know it'd all be the epitome of annoying boilerplate code, but my point 
is that if someone wants to subclass something of yours, there's really not 
much you can do to stop them.

(Before anyone mentions it, yes, the same trick can be used to get around 
`final` and `sealed`, but IIRC the motivations there were to enable certain 
compiler optimizations, not to prohibit "unauthorized" inheritance.)

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 9, 2016, at 7:59 AM, Andre via swift-evolution 
>  wrote:
> 
> Thanks for the thoughtful responses, its appreciated.
> 
>> 2016/07/09 23:30、Matthew Johnson  のメール：
>> 
>>> On Jul 9, 2016, at 8:39 AM, Andre  wrote:
>>> 
>>> Personally, Im not against sealed by default, but I think there are cases 
>>> where closed source libraries have certain cases where workarounds are 
>>> necessary, and just sealing by default will prevent those cases. 
>>> 
>>> One could say, "well just use an open source one, or change vendors" but 
>>> its not that easy in The Real World™ where we get certain SDKs shoved down 
>>> our throats by the suits… and while that may be a separate issue to the one 
>>> at hand, its still a problem that won’t resolve itself by simply locking 
>>> down things…
>>> 
>>> In my own case, Ive fought with NSBrowser / NSTreeController in the past 
>>> and the only way to resolve things was to subclass (and no, waiting 1 or 2 
>>> years for a fix is not acceptable if you already have a product in the 
>>> wild).
>>> 
>>> So I am reticent to support this proposal without an escape hatch for those 
>>> cases…
>> 
>> Are you concerned about closed-source vendor frameworks beyond Apple’s?  
>> Some things to consider:
>> 
>> 1. This proposal should not impact any existing libraries - nobody should be 
>> shipping closed-source binary libraries written in Swift yet.
>> 
>> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
>> come.  If / when they are replaced with Swift frameworks the default will 
>> have little (if any) impact on the public API contract.  It is reasonable to 
>> expect that Apple will review the public contracts carefully and add any 
>> annotations necessary to achieve the desired semantics.
>> 
>> 3. In the future, if you depend on any 3rd party closed-source libraries 
>> written in Swift you will be able to ship an update to your app that 
>> contains an updated / fixed version of the library independent of the user 
>> upgrading their OS.
> 
> I see, makes sense and I get a better idea where this is going… its how I 
> feel as well...
> 
>> This leaves the scenario of a case where you depend on a 3rd party, 
>> closed-source library written in Swift and where you cannot get (or use) a 
>> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
>> it is not large enough to outweigh all of the advantages of making sealed 
>> the default.  
> What are your thoughts on an ability for a way to force unseal a class that 
> does need to be fixed, even if its temporary?
> 
> Something like:
> 
> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits a 
> scary compiler warning
> }
> 
> Does that even seem feasible/possible, much less reasonable…?

I am also of the opinion that we need an "escape hatch" and I think Joe G 
notion of patch-ability should be part of this review. 

Alternatively I think at least having a way to add:

patch extension mySealedClass {
defer(methodOnClass(label01:,etc:) ){
 /// code I want to run right after method.  
}
}

I think something that is able to run right after a method would help at least 
some until the library author is able to fix the class. There is probably a 
small cost on attaching defer code to method but you won't need to subclass to 
fix certain bugs. 



> Though it would have to be a perhaps separate discussion, this comes to my 
> mind as becoming necessary down the road, but maybe I’m wrong...
> 
>> There is no doubt that adopting sealed by default will place some pressure 
>> on the Swift ecosystem.  As others have noted, this pressure already exists 
>> in the form of value types, protocol-oriented designs, etc - the current 
>> proposal is a relatively modest increase in that pressure.   I believe the 
>> pressure will have a very positive impact over time (the eventual outcome 
>> remains to be seen of course).  
> This is also, to me, a thing I am concerned about… its kind of an unknown I 
> suppose...
> 
>> Swift library vendors will need to choose between opening their source, 
>> providing responsive support and bug fixes, explicitly providing the escape 
>> hatch you mention (by designing with open types) or getting a bad reputation 
>> among users.
> Yes…. Well, anything that gets third parties to open up their closed 
> frameworks is a big win-win IMO… some of them are not very good (to put it 
> mildly) and could use more scrutiny.
> 
>> I have seen some comments about nontrivial complexity in Apple’s frameworks 
>> caused by apps subclassing where they should not have (i.e. classes that 
>> would be sealed if it were possible in Objective-C).  This is extremely 
>> unfortunate and it impacts everyone on Apple’s platforms.
>> 
>> I wish I had links handy for you, but I don’t recall exactly where or when 
>> this was mentioned and don’t have time to dig them up right now.
> 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution 
>  a écrit :
> 
> 
> Regards
> (From mobile)
> 
> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>>> On Jul 9, 2016, at 8:39 AM, Andre >> > wrote:
>>> 
>>> Personally, Im not against sealed by default, but I think there are cases 
>>> where closed source libraries have certain cases where workarounds are 
>>> necessary, and just sealing by default will prevent those cases. 
>>> 
>>> One could say, "well just use an open source one, or change vendors" but 
>>> its not that easy in The Real World™ where we get certain SDKs shoved down 
>>> our throats by the suits… and while that may be a separate issue to the one 
>>> at hand, its still a problem that won’t resolve itself by simply locking 
>>> down things…
>>> 
>>> In my own case, Ive fought with NSBrowser / NSTreeController in the past 
>>> and the only way to resolve things was to subclass (and no, waiting 1 or 2 
>>> years for a fix is not acceptable if you already have a product in the 
>>> wild).
>>> 
>>> So I am reticent to support this proposal without an escape hatch for those 
>>> cases…
>> 
>> Are you concerned about closed-source vendor frameworks beyond Apple’s?  
>> Some things to consider:
>> 
>> 1. This proposal should not impact any existing libraries - nobody should be 
>> shipping closed-source binary libraries written in Swift yet.
>> 
>> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
>> come.  If / when they are replaced with Swift frameworks the default will 
>> have little (if any) impact on the public API contract.  It is reasonable to 
>> expect that Apple will review the public contracts carefully and add any 
>> annotations necessary to achieve the desired semantics.
>> 
>> 3. In the future, if you depend on any 3rd party closed-source libraries 
>> written in Swift you will be able to ship an update to your app that 
>> contains an updated / fixed version of the library independent of the user 
>> upgrading their OS.
>> 
>> This leaves the scenario of a case where you depend on a 3rd party, 
>> closed-source library written in Swift and where you cannot get (or use) a 
>> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
>> it is not large enough to outweigh all of the advantages of making sealed 
>> the default.  
>> 
>> There is no doubt that adopting sealed by default will place some pressure 
>> on the Swift ecosystem.  As others have noted, this pressure already exists 
>> in the form of value types, protocol-oriented designs, etc - the current 
>> proposal is a relatively modest increase in that pressure.   I believe the 
>> pressure will have a very positive impact over time (the eventual outcome 
>> remains to be seen of course).  
>> 
>> Swift library vendors will need to choose between opening their source, 
>> providing responsive support and bug fixes, explicitly providing the escape 
>> hatch you mention (by designing with open types) or getting a bad reputation 
>> among users.
> 
> There are IMO no advantages to sealing by default. If there were, I cannot 
> imagine how they can have so consistently eluded the designers and 
> maintainers of so many great OOD languages in the last 30 years. Does it mean 
> it is just a matter of time for the core team to take it the c++ 
> standardization committee to make sure C++ gets enhanced the same way?
> 

You can’t compare Swift to C++ here. C++ uses « final » method and static 
dispatch by default, so subclassing does not imply the same fragility than with 
a fully dynamic language.


>> 
>> -Matthew
>> 
>>> 
>>> Andre
>>> 
 2016/07/09 22:11、Shawn Erickson > のメール：
 
 What I don't get in the arguments against this capability is the fact that 
 many constructs in Swift can't be subclassed. Are we going to prevent 
 library developers from presenting those in the public API? Your ability 
 to subclass things when not supported by the library developer is already 
 going to be greatly reduced. Additionally you are going to miss 
 potentially helpful optimization in side the model if the library 
 developer can't prevent extras subclassing.
 
 It seems perfectly reasonable to allow a lot of freedoms for a library 
 developer when designing their code on their side of the library API and 
 not force them to expose unwanted API just because of internal design 
 desires. 
 
 (I have myself have already struggled with having to leak what I consider 
 internal details outside of modules we have developed internally, likely 
 need to get around to outlining the additional issues I see)
 
 In the end if the library isn't good and you don't like the API find one 
 that 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Forking is desirable if your goals, needs, values, etc are substantially 
> different than the library author such that you do not agree on what the API 
> contract should look like.
That's desirable in the same sense as an amputation that saves you from a 
deadly sepsis... I'd rather stay away from both situations.
Forking drains manpower from real improvements, and the same is true for 
trivial pull-requests that can be avoided in the first place by keeping the 
defaults as they are.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Shawn Erickson via swift-evolution]

I fall more in Matthew side of this regarding sealed by default.
On Sat, Jul 9, 2016 at 12:29 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
> >
> >
> >> Of course it can be done either way.  But there are significant
> ecosystem robustness advantages to making sealed the default and
> comparatively few downsides.  Most libraries are open source (so can be
> modified directly or via PR if necessary)
> > First:
> > The claim about robustness sounds like a fact, despite being just an
> opinion (feel free to correct me if you have any evidence at all). We
> should stay honest with our predictions.
> > Second:
> > Do you really believe there will be positive impact on open-source
> libraries?
> > My forecast is that closed by default will dramatically increase trivial
> pull request where developers ask for unsealing so that they can do as they
> like…
>
> I think this is a good thing.  It will force a considered answer and a
> discussion about whether or not subclassing should be supported by the
> library.
>
> > and I've no idea why somebody could come up with the idea that forking
> is desirable.
>
> Forking is desirable if your goals, needs, values, etc are substantially
> different than the library author such that you do not agree on what the
> API contract should look like.
>
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> Of course it can be done either way.  But there are significant ecosystem 
>> robustness advantages to making sealed the default and comparatively few 
>> downsides.  Most libraries are open source (so can be modified directly or 
>> via PR if necessary)
> First:
> The claim about robustness sounds like a fact, despite being just an opinion 
> (feel free to correct me if you have any evidence at all). We should stay 
> honest with our predictions.
> Second:
> Do you really believe there will be positive impact on open-source libraries?
> My forecast is that closed by default will dramatically increase trivial pull 
> request where developers ask for unsealing so that they can do as they like…

I think this is a good thing.  It will force a considered answer and a 
discussion about whether or not subclassing should be supported by the library. 
 

> and I've no idea why somebody could come up with the idea that forking is 
> desirable.

Forking is desirable if your goals, needs, values, etc are substantially 
different than the library author such that you do not agree on what the API 
contract should look like.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jul 9, 2016, at 8:39 AM, Andre  wrote:
>> 
>> Personally, Im not against sealed by default, but I think there are cases 
>> where closed source libraries have certain cases where workarounds are 
>> necessary, and just sealing by default will prevent those cases. 
>> 
>> One could say, "well just use an open source one, or change vendors" but its 
>> not that easy in The Real World™ where we get certain SDKs shoved down our 
>> throats by the suits… and while that may be a separate issue to the one at 
>> hand, its still a problem that won’t resolve itself by simply locking down 
>> things…
>> 
>> In my own case, Ive fought with NSBrowser / NSTreeController in the past and 
>> the only way to resolve things was to subclass (and no, waiting 1 or 2 years 
>> for a fix is not acceptable if you already have a product in the wild).
>> 
>> So I am reticent to support this proposal without an escape hatch for those 
>> cases…
> 
> Are you concerned about closed-source vendor frameworks beyond Apple’s?  Some 
> things to consider:
> 
> 1. This proposal should not impact any existing libraries - nobody should be 
> shipping closed-source binary libraries written in Swift yet.
> 
> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
> come.  If / when they are replaced with Swift frameworks the default will 
> have little (if any) impact on the public API contract.  It is reasonable to 
> expect that Apple will review the public contracts carefully and add any 
> annotations necessary to achieve the desired semantics.
> 
> 3. In the future, if you depend on any 3rd party closed-source libraries 
> written in Swift you will be able to ship an update to your app that contains 
> an updated / fixed version of the library independent of the user upgrading 
> their OS.
> 
> This leaves the scenario of a case where you depend on a 3rd party, 
> closed-source library written in Swift and where you cannot get (or use) a 
> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
> it is not large enough to outweigh all of the advantages of making sealed the 
> default.  
> 
> There is no doubt that adopting sealed by default will place some pressure on 
> the Swift ecosystem.  As others have noted, this pressure already exists in 
> the form of value types, protocol-oriented designs, etc - the current 
> proposal is a relatively modest increase in that pressure.   I believe the 
> pressure will have a very positive impact over time (the eventual outcome 
> remains to be seen of course).  
> 
> Swift library vendors will need to choose between opening their source, 
> providing responsive support and bug fixes, explicitly providing the escape 
> hatch you mention (by designing with open types) or getting a bad reputation 
> among users.

There are IMO no advantages to sealing by default. If there were, I cannot 
imagine how they can have so consistently eluded the designers and maintainers 
of so many great OOD languages in the last 30 years. Does it mean it is just a 
matter of time for the core team to take it the c++ standardization committee 
to make sure C++ gets enhanced the same way?

> 
> -Matthew
> 
>> 
>> Andre
>> 
>>> 2016/07/09 22:11、Shawn Erickson  のメール：
>>> 
>>> What I don't get in the arguments against this capability is the fact that 
>>> many constructs in Swift can't be subclassed. Are we going to prevent 
>>> library developers from presenting those in the public API? Your ability to 
>>> subclass things when not supported by the library developer is already 
>>> going to be greatly reduced. Additionally you are going to miss potentially 
>>> helpful optimization in side the model if the library developer can't 
>>> prevent extras subclassing.
>>> 
>>> It seems perfectly reasonable to allow a lot of freedoms for a library 
>>> developer when designing their code on their side of the library API and 
>>> not force them to expose unwanted API just because of internal design 
>>> desires. 
>>> 
>>> (I have myself have already struggled with having to leak what I consider 
>>> internal details outside of modules we have developed internally, likely 
>>> need to get around to outlining the additional issues I see)
>>> 
>>> In the end if the library isn't good and you don't like the API find one 
>>> that works the way you need (or make one). I expect a fairly rich 
>>> environment of libraries that will sort itself out over time.
>>> 
>>> -Shawn
 On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution 
  wrote:
 Hi,
 
 > However, you *do not* want any new subclasses added as you know that is 
 > not likely to end well.
 Im curious, what kind of real-world scenario would "not end well" cover?
 
 I’m genuinely curious, since Im still 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> Of course it can be done either way.  But there are significant ecosystem 
> robustness advantages to making sealed the default and comparatively few 
> downsides.  Most libraries are open source (so can be modified directly or 
> via PR if necessary)
First:
The claim about robustness sounds like a fact, despite being just an opinion 
(feel free to correct me if you have any evidence at all). We should stay 
honest with our predictions.
Second:
Do you really believe there will be positive impact on open-source libraries?
My forecast is that closed by default will dramatically increase trivial pull 
request where developers ask for unsealing so that they can do as they like… 
and I've no idea why somebody could come up with the idea that forking is 
desirable.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

Thanks for the thoughtful responses, its appreciated.

> 2016/07/09 23:30、Matthew Johnson  のメール：
> 
>> On Jul 9, 2016, at 8:39 AM, Andre > 
>> wrote:
>> 
>> Personally, Im not against sealed by default, but I think there are cases 
>> where closed source libraries have certain cases where workarounds are 
>> necessary, and just sealing by default will prevent those cases. 
>> 
>> One could say, "well just use an open source one, or change vendors" but its 
>> not that easy in The Real World™ where we get certain SDKs shoved down our 
>> throats by the suits… and while that may be a separate issue to the one at 
>> hand, its still a problem that won’t resolve itself by simply locking down 
>> things…
>> 
>> In my own case, Ive fought with NSBrowser / NSTreeController in the past and 
>> the only way to resolve things was to subclass (and no, waiting 1 or 2 years 
>> for a fix is not acceptable if you already have a product in the wild).
>> 
>> So I am reticent to support this proposal without an escape hatch for those 
>> cases…
> 
> Are you concerned about closed-source vendor frameworks beyond Apple’s?  Some 
> things to consider:
> 
> 1. This proposal should not impact any existing libraries - nobody should be 
> shipping closed-source binary libraries written in Swift yet.
> 
> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
> come.  If / when they are replaced with Swift frameworks the default will 
> have little (if any) impact on the public API contract.  It is reasonable to 
> expect that Apple will review the public contracts carefully and add any 
> annotations necessary to achieve the desired semantics.
> 
> 3. In the future, if you depend on any 3rd party closed-source libraries 
> written in Swift you will be able to ship an update to your app that contains 
> an updated / fixed version of the library independent of the user upgrading 
> their OS.

I see, makes sense and I get a better idea where this is going… its how I feel 
as well...

> This leaves the scenario of a case where you depend on a 3rd party, 
> closed-source library written in Swift and where you cannot get (or use) a 
> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
> it is not large enough to outweigh all of the advantages of making sealed the 
> default.  
What are your thoughts on an ability for a way to force unseal a class that 
does need to be fixed, even if its temporary?

Something like:

class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits a 
scary compiler warning
}

Does that even seem feasible/possible, much less reasonable…?
Though it would have to be a perhaps separate discussion, this comes to my mind 
as becoming necessary down the road, but maybe I’m wrong...

> There is no doubt that adopting sealed by default will place some pressure on 
> the Swift ecosystem.  As others have noted, this pressure already exists in 
> the form of value types, protocol-oriented designs, etc - the current 
> proposal is a relatively modest increase in that pressure.   I believe the 
> pressure will have a very positive impact over time (the eventual outcome 
> remains to be seen of course).  
This is also, to me, a thing I am concerned about… its kind of an unknown I 
suppose...

> Swift library vendors will need to choose between opening their source, 
> providing responsive support and bug fixes, explicitly providing the escape 
> hatch you mention (by designing with open types) or getting a bad reputation 
> among users.
Yes…. Well, anything that gets third parties to open up their closed frameworks 
is a big win-win IMO… some of them are not very good (to put it mildly) and 
could use more scrutiny.

> I have seen some comments about nontrivial complexity in Apple’s frameworks 
> caused by apps subclassing where they should not have (i.e. classes that 
> would be sealed if it were possible in Objective-C).  This is extremely 
> unfortunate and it impacts everyone on Apple’s platforms.
> 
> I wish I had links handy for you, but I don’t recall exactly where or when 
> this was mentioned and don’t have time to dig them up right now.
I see, thats reasonable… if those links are available somewhere I would 
definitely like to see them, it would be a good education for me…

---

A little more for me to think about, but maybe I can cast a vote in a little 
bit…

Again, thanks for the thoughtful response!

Andre



>> 
>> Andre
>> 
>>> 2016/07/09 22:11、Shawn Erickson >> > のメール：
>>> 
>>> What I don't get in the arguments against this capability is the fact that 
>>> many constructs in Swift can't be subclassed. Are we going to prevent 
>>> library developers from presenting those in the public API? Your ability to 
>>> subclass things when not supported by the library developer is already 
>>> going to be greatly reduced. Additionally you are 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Shawn Erickson via swift-evolution]

When I expose an API it is to hide details behind it for the benefit of
myself - as the library developer - and to benefit the library user by
hiding complexity and giving them a well testable and tested contract. The
"myself" benefit also benefits consumers of the library since it gives me
the ability to more freely rework things under the hood overtime since I
was able to bound what users of my libraries should have been able to do
(in code dependency terms). I also can limit how much defensive programming
I may need to do.

I don't really see that as an attitude against users of a library.

Also note again I am going to present you with an API that in the swift
realm will have very few subclass able points, it will be protocol based
likely and heavier in structs, etc

Anyway it would be good to separate the votes against closed by default
from those against the ability to close a public class.

-Shawn


On Sat, Jul 9, 2016 at 9:37 AM Goffredo Marocchi  wrote:

>
>
> Sent from my iPhone
>
> On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What I don't get in the arguments against this capability is the fact that
> many constructs in Swift can't be subclassed. Are we going to prevent
> library developers from presenting those in the public API? Your ability to
> subclass things when not supported by the library developer is already
> going to be greatly reduced. Additionally you are going to miss potentially
> helpful optimization in side the model if the library developer can't
> prevent extras subclassing.
>
>
> This is one case where the automagical optimisation comes at a cost that
> you should be knowingly paying for. An explicit keyword that seals the
> class across module boundaries seems like would do the job just fine.
>
> Also, sorry for the off topic here, libraries are meant to be used by
> others and developed for others and we should have helping others in mind
> developing them. We also should be humble enough to admit that we will not
> be able to explicitly allow/predict all use cases and empowering our users
> to experiment, report issues, and add features through pull requests. The
> attitude behind some of the sealed by default reasons I have seen here does
> not seem it is what we should have in open source software. We do not want
> a situation where the library author puts the library and not the users on
> the pedestal.
>
> It seems perfectly reasonable to allow a lot of freedoms for a library
> developer when designing their code on their side of the library API and
> not force them to expose unwanted API just because of internal design
> desires.
>
> (I have myself have already struggled with having to leak what I consider
> internal details outside of modules we have developed internally, likely
> need to get around to outlining the additional issues I see)
>
> In the end if the library isn't good and you don't like the API find one
> that works the way you need (or make one). I expect a fairly rich
> environment of libraries that will sort itself out over time.
>
> -Shawn
> On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi,
>>
>> > However, you *do not* want any new subclasses added as you know that is
>> not likely to end well.
>> Im curious, what kind of real-world scenario would "not end well" cover?
>>
>> I’m genuinely curious, since Im still on the fence about this, but am
>> willing to be convinced… if sealed by default brings more positives than
>> negatives…
>>
>> Thanks in advance.
>>
>> Andre
>>
>>
>> > 2016/07/09 21:36、Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> のメール：
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>>
>> >>> Even in Java, it is a bad idea to leave classes subclassable; but
>> having to remember to add final is a chore.
>> >>
>> >> I still think it is worth doing that chore. The fact of the matter is
>> that Java did not and is not enforcing that default and how many widely
>> used production languages you know that do enforce this by default instead
>> of asking library authors to do this bit of work?
>> >
>> > People keep talking about just adding final.  This *is not* an
>> alternative.  We are not talking about preventing subclasses by default
>> (i.e. final by default).
>> >
>> > We are talking about preventing subclasses *in other modules* by
>> default (i.e. sealed by default).  The alternative would be to introduce a
>> sealed keyword (or similar).
>> >
>> > There are times when you *need* to use subclasses inside your module.
>> Some or all of them may not even be directly visible externally (class
>> clusters).  However, you *do not* want 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

> On Jul 9, 2016, at 7:43 AM, Andre  wrote:
> 
> Hi,
> 
>> However, you *do not* want any new subclasses added as you know that is not 
>> likely to end well. 
> Im curious, what kind of real-world scenario would "not end well" cover?

Any kind of scenario where you need to preserve invariants which could be 
difficult to preserve if you have to anticipate what 3rd party subclasses might 
do in their implementations / overrides.

I have seen some comments about nontrivial complexity in Apple’s frameworks 
caused by apps subclassing where they should not have (i.e. classes that would 
be sealed if it were possible in Objective-C).  This is extremely unfortunate 
and it impacts everyone on Apple’s platforms.

I wish I had links handy for you, but I don’t recall exactly where or when this 
was mentioned and don’t have time to dig them up right now.

> 
> I’m genuinely curious, since Im still on the fence about this, but am willing 
> to be convinced… if sealed by default brings more positives than negatives…
> 
> Thanks in advance.
> 
> Andre
> 
> 
>> 2016/07/09 21:36、Matthew Johnson via swift-evolution 
>>  のメール：
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
  wrote:
 
 Even in Java, it is a bad idea to leave classes subclassable; but having 
 to remember to add final is a chore.
>>> 
>>> I still think it is worth doing that chore. The fact of the matter is that 
>>> Java did not and is not enforcing that default and how many widely used 
>>> production languages you know that do enforce this by default instead of 
>>> asking library authors to do this bit of work?
>> 
>> People keep talking about just adding final.  This *is not* an alternative.  
>> We are not talking about preventing subclasses by default (i.e. final by 
>> default).  
>> 
>> We are talking about preventing subclasses *in other modules* by default 
>> (i.e. sealed by default).  The alternative would be to introduce a sealed 
>> keyword (or similar).
>> 
>> There are times when you *need* to use subclasses inside your module.  Some 
>> or all of them may not even be directly visible externally (class clusters). 
>>  However, you *do not* want any new subclasses added as you know that is not 
>> likely to end well.  This is why having sealed, not just final, is important.
>> 
>> By choosing sealed as a default rather than final, we are keeping the 
>> "subclassable by default" status *within* modules.  This facilitates 
>> experimentation and eliminates the need for application level code to opt-in 
>> to subclassing while still making external API contracts explicit and 
>> therefore hopefully more robust.  It is the default most in-line with the 
>> values and goals of Swift.
>> 
>> 'final' and 'sealed' are two very different things.  Let's please keep this 
>> focused on what is actually being proposed.
>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 9, 2016, at 8:37 AM, Goffredo Marocchi  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution 
>>  wrote:
>> 
>> What I don't get in the arguments against this capability is the fact that 
>> many constructs in Swift can't be subclassed. Are we going to prevent 
>> library developers from presenting those in the public API? Your ability to 
>> subclass things when not supported by the library developer is already going 
>> to be greatly reduced. Additionally you are going to miss potentially 
>> helpful optimization in side the model if the library developer can't 
>> prevent extras subclassing.
> 
> This is one case where the automagical optimisation comes at a cost that you 
> should be knowingly paying for. An explicit keyword that seals the class 
> across module boundaries seems like would do the job just fine.
> 
> Also, sorry for the off topic here, libraries are meant to be used by others 
> and developed for others and we should have helping others in mind developing 
> them. We also should be humble enough to admit that we will not be able to 
> explicitly allow/predict all use cases and empowering our users to 
> experiment, report issues, and add features through pull requests. The 
> attitude behind some of the sealed by default reasons I have seen here does 
> not seem it is what we should have in open source software. We do not want a 
> situation where the library author puts the library and not the users on the 
> pedestal.

Nobody is trying to do that.  We want an ecosystem that consists of robust, 
well-designed libraries whose contracts are explicit.  Nobody is proposing 
restricting the ability of a library to expose externally subclassable types.  

We are only discussing how to handle cases where the library author has not 
considered external subclasses in their design and made that consideration 
explicit by adding the appropriate modifier.  I don't see why this is too large 
a burden to ask of a library author who truly cares about giving users the best 
experience possible.  

We want sealed to be the default precisely because we care *more* about the 
experience of library users than we do about library authors (specifically, 
requiring annotation in the library code).

> 
>> It seems perfectly reasonable to allow a lot of freedoms for a library 
>> developer when designing their code on their side of the library API and not 
>> force them to expose unwanted API just because of internal design desires. 
>> 
>> (I have myself have already struggled with having to leak what I consider 
>> internal details outside of modules we have developed internally, likely 
>> need to get around to outlining the additional issues I see)
>> 
>> In the end if the library isn't good and you don't like the API find one 
>> that works the way you need (or make one). I expect a fairly rich 
>> environment of libraries that will sort itself out over time.
>> 
>> -Shawn
>>> On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution 
>>>  wrote:
>>> Hi,
>>> 
>>> > However, you *do not* want any new subclasses added as you know that is 
>>> > not likely to end well.
>>> Im curious, what kind of real-world scenario would "not end well" cover?
>>> 
>>> I’m genuinely curious, since Im still on the fence about this, but am 
>>> willing to be convinced… if sealed by default brings more positives than 
>>> negatives…
>>> 
>>> Thanks in advance.
>>> 
>>> Andre
>>> 
>>> 
>>> > 2016/07/09 21:36、Matthew Johnson via swift-evolution 
>>> >  のメール：
>>> >
>>> >
>>> >
>>> > Sent from my iPad
>>> >
>>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>>> >>  wrote:
>>> >>
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>>> >>>  wrote:
>>> >>>
>>> >>> Even in Java, it is a bad idea to leave classes subclassable; but 
>>> >>> having to remember to add final is a chore.
>>> >>
>>> >> I still think it is worth doing that chore. The fact of the matter is 
>>> >> that Java did not and is not enforcing that default and how many widely 
>>> >> used production languages you know that do enforce this by default 
>>> >> instead of asking library authors to do this bit of work?
>>> >
>>> > People keep talking about just adding final.  This *is not* an 
>>> > alternative.  We are not talking about preventing subclasses by default 
>>> > (i.e. final by default).
>>> >
>>> > We are talking about preventing subclasses *in other modules* by default 
>>> > (i.e. sealed by default).  The alternative would be to introduce a sealed 
>>> > keyword (or similar).
>>> >
>>> > There are times when you *need* to use subclasses inside your module.  
>>> > Some or all of them may not even be directly visible externally (class 
>>> > 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 9, 2016, at 8:31 AM, Goffredo Marocchi  wrote:
> 
> Ok, then I should ask you to consider what I said earlier and substitute 
> "final by default" with "sealed by default" and if we have this sealed 
> keyword not to make it the default. 
> Trust coders and people a bit more instead of resorting to more involved 
> obligatory processes instead. Do we really need in this case to seal modules 
> by default? Can we just have a keyword that the library author can use and 
> express this intent explicitly?

Of course it can be done either way.  But there are significant ecosystem 
robustness advantages to making sealed the default and comparatively few 
downsides.  Most libraries are open source (so can be modified directly or via 
PR if necessary) and Apple would likely use sealed widely in any Swift native 
APIs even if it must be stated explicitly.  

Sealed is the Swiftiest default.  It makes public API contracts explicit.  This 
is safer, more robust and adds clarity (you don't need to wonder whether an API 
author intended to support external subclassing, does not want external 
subclassing but supports needs it internally, or simply hasn't given it any 
thought)

> 
> Usually, look at some countries like Italy in a legislative sense, when you 
> attempt to regulate in a way that everything is kind of banned except what 
> you explicitly allow you get more convoluted, complex, and nerve wrecking 
> solutions than allowing everything except what you explicitly ban (reviewing 
> it all over time of course).

I don't see how comparing the domains of programming language design and 
politics / economic regulation makes any sense at all.

> 
> Sent from my iPhone
> 
>> On 9 Jul 2016, at 13:36, Matthew Johnson  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
  wrote:
 
 Even in Java, it is a bad idea to leave classes subclassable; but having 
 to remember to add final is a chore.
>>> 
>>> I still think it is worth doing that chore. The fact of the matter is that 
>>> Java did not and is not enforcing that default and how many widely used 
>>> production languages you know that do enforce this by default instead of 
>>> asking library authors to do this bit of work?
>> 
>> People keep talking about just adding final.  This *is not* an alternative.  
>> We are not talking about preventing subclasses by default (i.e. final by 
>> default).  
>> 
>> We are talking about preventing subclasses *in other modules* by default 
>> (i.e. sealed by default).  The alternative would be to introduce a sealed 
>> keyword (or similar).
>> 
>> There are times when you *need* to use subclasses inside your module.  Some 
>> or all of them may not even be directly visible externally (class clusters). 
>>  However, you *do not* want any new subclasses added as you know that is not 
>> likely to end well.  This is why having sealed, not just final, is important.
>> 
>> By choosing sealed as a default rather than final, we are keeping the 
>> "subclassable by default" status *within* modules.  This facilitates 
>> experimentation and eliminates the need for application level code to opt-in 
>> to subclassing while still making external API contracts explicit and 
>> therefore hopefully more robust.  It is the default most in-line with the 
>> values and goals of Swift.
>> 
>> 'final' and 'sealed' are two very different things.  Let's please keep this 
>> focused on what is actually being proposed.
>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

Personally, Im not against sealed by default, but I think there are cases where 
closed source libraries have certain cases where workarounds are necessary, and 
just sealing by default will prevent those cases. 

One could say, "well just use an open source one, or change vendors" but its 
not that easy in The Real World™ where we get certain SDKs shoved down our 
throats by the suits… and while that may be a separate issue to the one at 
hand, its still a problem that won’t resolve itself by simply locking down 
things…

In my own case, Ive fought with NSBrowser / NSTreeController in the past and 
the only way to resolve things was to subclass (and no, waiting 1 or 2 years 
for a fix is not acceptable if you already have a product in the wild).

So I am reticent to support this proposal without an escape hatch for those 
cases…

Andre

> 2016/07/09 22:11、Shawn Erickson  のメール：
> 
> What I don't get in the arguments against this capability is the fact that 
> many constructs in Swift can't be subclassed. Are we going to prevent library 
> developers from presenting those in the public API? Your ability to subclass 
> things when not supported by the library developer is already going to be 
> greatly reduced. Additionally you are going to miss potentially helpful 
> optimization in side the model if the library developer can't prevent extras 
> subclassing.
> 
> It seems perfectly reasonable to allow a lot of freedoms for a library 
> developer when designing their code on their side of the library API and not 
> force them to expose unwanted API just because of internal design desires. 
> 
> (I have myself have already struggled with having to leak what I consider 
> internal details outside of modules we have developed internally, likely need 
> to get around to outlining the additional issues I see)
> 
> In the end if the library isn't good and you don't like the API find one that 
> works the way you need (or make one). I expect a fairly rich environment of 
> libraries that will sort itself out over time.
> 
> -Shawn
> On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution 
> > wrote:
> Hi,
> 
> > However, you *do not* want any new subclasses added as you know that is not 
> > likely to end well.
> Im curious, what kind of real-world scenario would "not end well" cover?
> 
> I’m genuinely curious, since Im still on the fence about this, but am willing 
> to be convinced… if sealed by default brings more positives than negatives…
> 
> Thanks in advance.
> 
> Andre
> 
> 
> > 2016/07/09 21:36、Matthew Johnson via swift-evolution 
> > > のメール：
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
> >> > wrote:
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
> >>> > wrote:
> >>>
> >>> Even in Java, it is a bad idea to leave classes subclassable; but having 
> >>> to remember to add final is a chore.
> >>
> >> I still think it is worth doing that chore. The fact of the matter is that 
> >> Java did not and is not enforcing that default and how many widely used 
> >> production languages you know that do enforce this by default instead of 
> >> asking library authors to do this bit of work?
> >
> > People keep talking about just adding final.  This *is not* an alternative. 
> >  We are not talking about preventing subclasses by default (i.e. final by 
> > default).
> >
> > We are talking about preventing subclasses *in other modules* by default 
> > (i.e. sealed by default).  The alternative would be to introduce a sealed 
> > keyword (or similar).
> >
> > There are times when you *need* to use subclasses inside your module.  Some 
> > or all of them may not even be directly visible externally (class 
> > clusters).  However, you *do not* want any new subclasses added as you know 
> > that is not likely to end well.  This is why having sealed, not just final, 
> > is important.
> >
> > By choosing sealed as a default rather than final, we are keeping the 
> > "subclassable by default" status *within* modules.  This facilitates 
> > experimentation and eliminates the need for application level code to 
> > opt-in to subclassing while still making external API contracts explicit 
> > and therefore hopefully more robust.  It is the default most in-line with 
> > the values and goals of Swift.
> >
> > 'final' and 'sealed' are two very different things.  Let's please keep this 
> > focused on what is actually being proposed.
> >
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org 
> >> 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution 
>  wrote:
> 
> What I don't get in the arguments against this capability is the fact that 
> many constructs in Swift can't be subclassed. Are we going to prevent library 
> developers from presenting those in the public API? Your ability to subclass 
> things when not supported by the library developer is already going to be 
> greatly reduced. Additionally you are going to miss potentially helpful 
> optimization in side the model if the library developer can't prevent extras 
> subclassing.
> 

This is one case where the automagical optimisation comes at a cost that you 
should be knowingly paying for. An explicit keyword that seals the class across 
module boundaries seems like would do the job just fine.

Also, sorry for the off topic here, libraries are meant to be used by others 
and developed for others and we should have helping others in mind developing 
them. We also should be humble enough to admit that we will not be able to 
explicitly allow/predict all use cases and empowering our users to experiment, 
report issues, and add features through pull requests. The attitude behind some 
of the sealed by default reasons I have seen here does not seem it is what we 
should have in open source software. We do not want a situation where the 
library author puts the library and not the users on the pedestal.

> It seems perfectly reasonable to allow a lot of freedoms for a library 
> developer when designing their code on their side of the library API and not 
> force them to expose unwanted API just because of internal design desires. 
> 
> (I have myself have already struggled with having to leak what I consider 
> internal details outside of modules we have developed internally, likely need 
> to get around to outlining the additional issues I see)
> 
> In the end if the library isn't good and you don't like the API find one that 
> works the way you need (or make one). I expect a fairly rich environment of 
> libraries that will sort itself out over time.
> 
> -Shawn
>> On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution 
>>  wrote:
>> Hi,
>> 
>> > However, you *do not* want any new subclasses added as you know that is 
>> > not likely to end well.
>> Im curious, what kind of real-world scenario would "not end well" cover?
>> 
>> I’m genuinely curious, since Im still on the fence about this, but am 
>> willing to be convinced… if sealed by default brings more positives than 
>> negatives…
>> 
>> Thanks in advance.
>> 
>> Andre
>> 
>> 
>> > 2016/07/09 21:36、Matthew Johnson via swift-evolution 
>> >  のメール：
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>> >>  wrote:
>> >>
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> Even in Java, it is a bad idea to leave classes subclassable; but having 
>> >>> to remember to add final is a chore.
>> >>
>> >> I still think it is worth doing that chore. The fact of the matter is 
>> >> that Java did not and is not enforcing that default and how many widely 
>> >> used production languages you know that do enforce this by default 
>> >> instead of asking library authors to do this bit of work?
>> >
>> > People keep talking about just adding final.  This *is not* an 
>> > alternative.  We are not talking about preventing subclasses by default 
>> > (i.e. final by default).
>> >
>> > We are talking about preventing subclasses *in other modules* by default 
>> > (i.e. sealed by default).  The alternative would be to introduce a sealed 
>> > keyword (or similar).
>> >
>> > There are times when you *need* to use subclasses inside your module.  
>> > Some or all of them may not even be directly visible externally (class 
>> > clusters).  However, you *do not* want any new subclasses added as you 
>> > know that is not likely to end well.  This is why having sealed, not just 
>> > final, is important.
>> >
>> > By choosing sealed as a default rather than final, we are keeping the 
>> > "subclassable by default" status *within* modules.  This facilitates 
>> > experimentation and eliminates the need for application level code to 
>> > opt-in to subclassing while still making external API contracts explicit 
>> > and therefore hopefully more robust.  It is the default most in-line with 
>> > the values and goals of Swift.
>> >
>> > 'final' and 'sealed' are two very different things.  Let's please keep 
>> > this focused on what is actually being proposed.
>> >
>> >>
>> >> ___
>> >> swift-evolution mailing list
>> >> swift-evolution@swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Ok, then I should ask you to consider what I said earlier and substitute "final 
by default" with "sealed by default" and if we have this sealed keyword not to 
make it the default. 
Trust coders and people a bit more instead of resorting to more involved 
obligatory processes instead. Do we really need in this case to seal modules by 
default? Can we just have a keyword that the library author can use and express 
this intent explicitly?

Usually, look at some countries like Italy in a legislative sense, when you 
attempt to regulate in a way that everything is kind of banned except what you 
explicitly allow you get more convoluted, complex, and nerve wrecking solutions 
than allowing everything except what you explicitly ban (reviewing it all over 
time of course).

Sent from my iPhone

> On 9 Jul 2016, at 13:36, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>>>  wrote:
>>> 
>>> Even in Java, it is a bad idea to leave classes subclassable; but having to 
>>> remember to add final is a chore.
>> 
>> I still think it is worth doing that chore. The fact of the matter is that 
>> Java did not and is not enforcing that default and how many widely used 
>> production languages you know that do enforce this by default instead of 
>> asking library authors to do this bit of work?
> 
> People keep talking about just adding final.  This *is not* an alternative.  
> We are not talking about preventing subclasses by default (i.e. final by 
> default).  
> 
> We are talking about preventing subclasses *in other modules* by default 
> (i.e. sealed by default).  The alternative would be to introduce a sealed 
> keyword (or similar).
> 
> There are times when you *need* to use subclasses inside your module.  Some 
> or all of them may not even be directly visible externally (class clusters).  
> However, you *do not* want any new subclasses added as you know that is not 
> likely to end well.  This is why having sealed, not just final, is important.
> 
> By choosing sealed as a default rather than final, we are keeping the 
> "subclassable by default" status *within* modules.  This facilitates 
> experimentation and eliminates the need for application level code to opt-in 
> to subclassing while still making external API contracts explicit and 
> therefore hopefully more robust.  It is the default most in-line with the 
> values and goals of Swift.
> 
> 'final' and 'sealed' are two very different things.  Let's please keep this 
> focused on what is actually being proposed.
> 
>> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Shawn Erickson via swift-evolution]

What I don't get in the arguments against this capability is the fact that
many constructs in Swift can't be subclassed. Are we going to prevent
library developers from presenting those in the public API? Your ability to
subclass things when not supported by the library developer is already
going to be greatly reduced. Additionally you are going to miss potentially
helpful optimization in side the model if the library developer can't
prevent extras subclassing.

It seems perfectly reasonable to allow a lot of freedoms for a library
developer when designing their code on their side of the library API and
not force them to expose unwanted API just because of internal design
desires.

(I have myself have already struggled with having to leak what I consider
internal details outside of modules we have developed internally, likely
need to get around to outlining the additional issues I see)

In the end if the library isn't good and you don't like the API find one
that works the way you need (or make one). I expect a fairly rich
environment of libraries that will sort itself out over time.

-Shawn
On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
>
> > However, you *do not* want any new subclasses added as you know that is
> not likely to end well.
> Im curious, what kind of real-world scenario would "not end well" cover?
>
> I’m genuinely curious, since Im still on the fence about this, but am
> willing to be convinced… if sealed by default brings more positives than
> negatives…
>
> Thanks in advance.
>
> Andre
>
>
> > 2016/07/09 21:36、Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> のメール：
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> Even in Java, it is a bad idea to leave classes subclassable; but
> having to remember to add final is a chore.
> >>
> >> I still think it is worth doing that chore. The fact of the matter is
> that Java did not and is not enforcing that default and how many widely
> used production languages you know that do enforce this by default instead
> of asking library authors to do this bit of work?
> >
> > People keep talking about just adding final.  This *is not* an
> alternative.  We are not talking about preventing subclasses by default
> (i.e. final by default).
> >
> > We are talking about preventing subclasses *in other modules* by default
> (i.e. sealed by default).  The alternative would be to introduce a sealed
> keyword (or similar).
> >
> > There are times when you *need* to use subclasses inside your module.
> Some or all of them may not even be directly visible externally (class
> clusters).  However, you *do not* want any new subclasses added as you know
> that is not likely to end well.  This is why having sealed, not just final,
> is important.
> >
> > By choosing sealed as a default rather than final, we are keeping the
> "subclassable by default" status *within* modules.  This facilitates
> experimentation and eliminates the need for application level code to
> opt-in to subclassing while still making external API contracts explicit
> and therefore hopefully more robust.  It is the default most in-line with
> the values and goals of Swift.
> >
> > 'final' and 'sealed' are two very different things.  Let's please keep
> this focused on what is actually being proposed.
> >
> >>
> >> ___
> >> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

Hi,

> However, you *do not* want any new subclasses added as you know that is not 
> likely to end well. 
Im curious, what kind of real-world scenario would "not end well" cover?

I’m genuinely curious, since Im still on the fence about this, but am willing 
to be convinced… if sealed by default brings more positives than negatives…

Thanks in advance.

Andre


> 2016/07/09 21:36、Matthew Johnson via swift-evolution 
>  のメール：
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>>>  wrote:
>>> 
>>> Even in Java, it is a bad idea to leave classes subclassable; but having to 
>>> remember to add final is a chore.
>> 
>> I still think it is worth doing that chore. The fact of the matter is that 
>> Java did not and is not enforcing that default and how many widely used 
>> production languages you know that do enforce this by default instead of 
>> asking library authors to do this bit of work?
> 
> People keep talking about just adding final.  This *is not* an alternative.  
> We are not talking about preventing subclasses by default (i.e. final by 
> default).  
> 
> We are talking about preventing subclasses *in other modules* by default 
> (i.e. sealed by default).  The alternative would be to introduce a sealed 
> keyword (or similar).
> 
> There are times when you *need* to use subclasses inside your module.  Some 
> or all of them may not even be directly visible externally (class clusters).  
> However, you *do not* want any new subclasses added as you know that is not 
> likely to end well.  This is why having sealed, not just final, is important.
> 
> By choosing sealed as a default rather than final, we are keeping the 
> "subclassable by default" status *within* modules.  This facilitates 
> experimentation and eliminates the need for application level code to opt-in 
> to subclassing while still making external API contracts explicit and 
> therefore hopefully more robust.  It is the default most in-line with the 
> values and goals of Swift.
> 
> 'final' and 'sealed' are two very different things.  Let's please keep this 
> focused on what is actually being proposed.
> 
>> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>>  wrote:
>> 
>> Even in Java, it is a bad idea to leave classes subclassable; but having to 
>> remember to add final is a chore.
> 
> I still think it is worth doing that chore. The fact of the matter is that 
> Java did not and is not enforcing that default and how many widely used 
> production languages you know that do enforce this by default instead of 
> asking library authors to do this bit of work?

People keep talking about just adding final.  This *is not* an alternative.  We 
are not talking about preventing subclasses by default (i.e. final by default). 
 

We are talking about preventing subclasses *in other modules* by default (i.e. 
sealed by default).  The alternative would be to introduce a sealed keyword (or 
similar).

There are times when you *need* to use subclasses inside your module.  Some or 
all of them may not even be directly visible externally (class clusters).  
However, you *do not* want any new subclasses added as you know that is not 
likely to end well.  This is why having sealed, not just final, is important.

By choosing sealed as a default rather than final, we are keeping the 
"subclassable by default" status *within* modules.  This facilitates 
experimentation and eliminates the need for application level code to opt-in to 
subclassing while still making external API contracts explicit and therefore 
hopefully more robust.  It is the default most in-line with the values and 
goals of Swift.

'final' and 'sealed' are two very different things.  Let's please keep this 
focused on what is actually being proposed.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution 
>  wrote:
> 
> Even in Java, it is a bad idea to leave classes subclassable; but having to 
> remember to add final is a chore.

I still think it is worth doing that chore. The fact of the matter is that Java 
did not and is not enforcing that default and how many widely used production 
languages you know that do enforce this by default instead of asking library 
authors to do this bit of work?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Garth Snyder via swift-evolution]

Strong -1 from me.

I think most of my thoughts on this have already been well covered by others. 
I’ll just note that this proposal reminds me of the fortune file entry, 
“Whenever you see a sign that says ‘no exit’, it means there is an exit there.”

Specifically, under this proposal, whenever you see a nonsubclassable, 
non-final class (which I suppose would in fact be any class not explicitly 
marked as subclassable), it would mean that the library implementor IS in fact 
subclassing it. Otherwise, it would just be final. Therefore, it’s by 
definition a perfectly reasonable class to specialize. The implementor just 
doesn’t want YOU doing it.

Maybe the implementor has a very good reason for this. But in the modal case, 
probably not. As the ladies on Jerry Springer say: you don’t know me; you don’t 
know my life. You really have no idea how I’ll be using your API or what I’ll 
be trying to achieve. In most cases, I'll have both your library source code 
and intimate knowledge of the application domain, so I’m probably in a better 
position than you to make these types of architectural assessments. You’re 
working with nothing but speculation, or even worse, your own myopic 
perspective of what your library is and how it ought be used. You think you 
know all about it because it’s Your Damn Library, but so very often, that 
conception turns out not to be not entirely accurate.

There’s a strong argument for allowing classes to be final, namely, static 
binding and performance. There’s a strong argument for allowing API to be 
nonpublic, namely, the ability to be clear about what’s included in the API and 
what’s not.

Beyond that, I really see no value in being able to schoolmarmishly forbid 
subclassing and overriding just out of conservatism, regardless of the syntax 
for this feature or the default behavior. If you want this, go write Ada code.

There should absolutely be a way to say “don’t subclass this.” But do you 
really need anything more than a comment that says “don’t subclass this?” 
Perhaps as a compromise, and as a concession to the value of automated 
checking, this feature could be reformulated as a warning system. A class 
marked as nonsubclassable could be extended only be including a corresponding 
acknowledgment keyword in the extending class, a kind of Swift version of 
-IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData.

Either way, I would be sad to see nonextentability become the default behavior 
of Swift. That just doesn’t seem like it’s in anyone’s best interest.

Garth

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[James Campbell via swift-evolution]

Personally I think a great compromise is just forcing the user to use the
`override` keyword when subclassing in these cases. That way the library
maker can mark classes that aren't supported or are internal and ideally
shouldn't be used by the programmer.

However we shouldn't baby sit programmers, we are smart people after all.
So if there is a huge catastrophic bug that just happens to be easily
solvable by subclassing or whatever then we should allow them to do so.

An `override` keyword would be a great compromise, take this class:

public class NonSubclassableParentClass {

}


If the programmer subclasses it normally, the compiler will throw an error
telling them to use the `override` keyword to subclass non-subclassble
classes:

override class  MySubclass: NonSubclassableParentClass {

}


Now there is a clear indicator that we are doing something not safe or
ideal here. This is similar how the "!" in IUO indicates we have a unsafe
value. We are grown-ups we should be able to know when to subclass but this
doesn't mean there couldn't be something like this to indicate to the user
that they may want to revaluate this in the future.

So in the future other programmers can see this marker and think "Oh we are
using this class in a non recommended way, so when it breaks when I upgrade
the library it's our fault." hopefully making them continue to upgrade
rather than not upgrading because it breaks "my subclass".

Whats great about this feature is it also allows linters or the compiler to
also show warnings when this is used as well, that way those of us that are
bugged by the amount of warnings we have in our app can endevour to fix it.

In Ruby there is a convention to have these sort of monkey patches and
subclasses to fix bugs in a special folder with "_ext" after it to indicate
that this an extension to a class from a library, this indicates to the
programmer that it's something we should ideally remove as soon as the app
can work without that hack.

So I can't see why we can't have this `override` keyword to tell the
library developer that we like to live life on the edge a litte ;)


*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 8 July 2016 at 22:14, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe
> there would have been significant benefits to Apple's platforms and
> ecosystem.  The reasons for believing (or not believing) this have been
> discussed in depth so there isn't a need to rehash them now.
>
> I'm not asking for reasons but for a single persuasive example…
>
> It is easy to claim that everything will be better if we add restrictions,
> but so far, I haven't heard of any real problems cause by the current
> defaults:
> The motivation to change them is not because of actual experience, it's
> just the trendy opinion that inheritance is evil.
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

The stories I’ve seen about things Apple’s frameworks need to deal with are 
another.  I don’t have links handy but they shouldn’t be too hard to find for 
anyone interested in looking.

> On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa  wrote:
> 
> I've sent one I currently have myself. Look back on the thread posts.
> 
> L
> 
> 
> On 8 July 2016 at 18:14, Tino Heth via swift-evolution
>  wrote:
>> 
>> When was the last time you you thought "I really wish the author of that
>> library had restricted my options to use it"?
>> 
>> 
>> I really wish Objective-C had this feature from the start.  I believe there
>> would have been significant benefits to Apple's platforms and ecosystem.
>> The reasons for believing (or not believing) this have been discussed in
>> depth so there isn't a need to rehash them now.
>> 
>> I'm not asking for reasons but for a single persuasive example…
>> 
>> It is easy to claim that everything will be better if we add restrictions,
>> but so far, I haven't heard of any real problems cause by the current
>> defaults:
>> The motivation to change them is not because of actual experience, it's just
>> the trendy opinion that inheritance is evil.
>> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I've sent one I currently have myself. Look back on the thread posts.

L


On 8 July 2016 at 18:14, Tino Heth via swift-evolution
 wrote:
>
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe there
> would have been significant benefits to Apple's platforms and ecosystem.
> The reasons for believing (or not believing) this have been discussed in
> depth so there isn't a need to rehash them now.
>
> I'm not asking for reasons but for a single persuasive example…
>
> It is easy to claim that everything will be better if we add restrictions,
> but so far, I haven't heard of any real problems cause by the current
> defaults:
> The motivation to change them is not because of actual experience, it's just
> the trendy opinion that inheritance is evil.
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

>> When was the last time you you thought "I really wish the author of that 
>> library had restricted my options to use it"?
> 
> I really wish Objective-C had this feature from the start.  I believe there 
> would have been significant benefits to Apple's platforms and ecosystem.  The 
> reasons for believing (or not believing) this have been discussed in depth so 
> there isn't a need to rehash them now.
I'm not asking for reasons but for a single persuasive example…

It is easy to claim that everything will be better if we add restrictions, but 
so far, I haven't heard of any real problems cause by the current defaults:
The motivation to change them is not because of actual experience, it's just 
the trendy opinion that inheritance is evil.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell via swift-evolution]

> On Jul 8, 2016, at 12:30 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Defaults matter, because they transmit a message:
> Every rule and obstacle we add to Swift is a statement that says "we favor 
> bureaucracy over freedom", and this will affect the community evolving around 
> the language.

…or “we favor mindfulness over carelessness,” or “we favor static type safety 
over runtime bug discovery.”

There are many ways of recoloring that thought.

> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that 
> library had restricted my options to use it"?

The correct question is:

When was the last time you thought, “I really wish the author of that library 
had thought carefully about where and how they expected people to extend it?”

I spend a lot of time in the Ruby world as well, where there is no static type 
safety at all, and the entire type structure of your program and all of its 
libraries is open for rewiring the whole time the program is running. And you 
know what? It works just fine in practice! I’d say it favors rapid prototyping 
at the expense of subtle bugs staying hidden longer than they otherwise might. 
That’s a tradeoff that’s worth it for many projects. Pros and cons aside, 
though, people build good software this way. Ruby’s “nothing is sealed, 
everything is Play-Doh” approach really does work in practice.

The interesting question is not _whether_ this works, but _why_ it works. Ruby 
coders know not to expect any correctness help from the compiler, and know what 
kinds of testing they need to do to verify that correctness by other means. 
They build systems with the expectation of unit correctness being no guarantee 
of integrated system correctness. An entire ecosystem of culture, habit, and 
expectations supports the language’s looseness.

Swift already — today, right now, even without this proposal — sets very 
different expectations. Developers _do_ expect certain kinds of help from the 
compiler. In particular, they expect that consequential design decisions are 
explicitly declared, and that where is is a default, it is the one that favors 
static verification. Subclassibility is a consequential design decision, and it 
is one that precludes certain kinds of static verification (because how 
overriding methods can break encapsulation). Making it the default thus 
contradicts the developer expectations that the language has already 
established.

The question is not whether sealed or open is the One True Way. The question is 
which fits into Swift’s particular ecosystem of culture, habit, and 
expectations.

This is engineering, folks. No gospel truths here; it’s all tradeoffs. Open by 
default can be the right tradeoff for one language, and the wrong one for 
another.

Cheers,

Paul



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Just to relax a bit, from reading this thread I cannot help but feel a
relation to Civil War. One can even say on which side everyone here
would stand for real. #TeamIronMan

L

On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution
 wrote:
>
>
> Sent from my iPad
>
> On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote:
>
>
> 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 is dramatic, and your whole argument is flawed because you miss the imho
> most important point.
>
>
> I didn't say it isn't dramatic, only that it isn't as dramatic a change as
> some commenters seem to suggest.
>
> This is not only a question of "will I be able to override this tiny method
> of UIView in the future?", but a question of attitude:
> When you do away with the rule of lenity and change it to "guilty by
> default", the direct impact is marginal as well — but it is a drastic change
> for the society as a whole.
>
>
> It's not about guilt or innocence, or any kind of lenience or punishment.
>
> It's mostly about whether we want to foster an ecosystem where public API
> contracts have been explicitly considered or not.  There are some ancillary
> benefits as well but those are much less important.
>
>
> Defaults matter, because they transmit a message:
>
>
> I agree.
>
> Every rule and obstacle we add to Swift is a statement that says "we favor
> bureaucracy over freedom", and this will affect the community evolving
> around the language.
> When you use a library in a way that wasn't anticipated by its author,
> you'll ran into issues occasionally; nonetheless, I think we should struggle
> for an open ecosystem that encourages others to experiment and fail, rather
> than to limit their possibilities in a futile attempt to protect them.
>
>
> In a majority of cases today this openness is better fostered by Github than
> "anything goes" public API.
>
>
> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe there
> would have been significant benefits to Apple's platforms and ecosystem.
> The reasons for believing (or not believing) this have been discussed in
> depth so there isn't a need to rehash them now.
>
> As a matter of fact, open by default forces nobody to subclass and override,
> so it's easy to avoid any problems caused by excessive hacking — closed by
> default, on the other hand, has impact not only on those who believe in
> restrictions, but on those who dislike them as well.
>
>
> Actually open by default has caused some very nontrivial difficulties for
> Apple's framework maintainers.  We all pay the price for this whether we
> engage in such subclassing and overriding or not.  I find that pretty
> unfortunate, especially for those of us who do find other ways to solve our
> problems.
>
> -Matthew
>
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> 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 is dramatic, and your whole argument is flawed because you miss the imho 
> most important point.

I didn't say it isn't dramatic, only that it isn't as dramatic a change as some 
commenters seem to suggest.

> This is not only a question of "will I be able to override this tiny method 
> of UIView in the future?", but a question of attitude:
> When you do away with the rule of lenity and change it to "guilty by 
> default", the direct impact is marginal as well — but it is a drastic change 
> for the society as a whole.

It's not about guilt or innocence, or any kind of lenience or punishment.  

It's mostly about whether we want to foster an ecosystem where public API 
contracts have been explicitly considered or not.  There are some ancillary 
benefits as well but those are much less important.

> 
> Defaults matter, because they transmit a message:

I agree.

> Every rule and obstacle we add to Swift is a statement that says "we favor 
> bureaucracy over freedom", and this will affect the community evolving around 
> the language.
> When you use a library in a way that wasn't anticipated by its author, you'll 
> ran into issues occasionally; nonetheless, I think we should struggle for an 
> open ecosystem that encourages others to experiment and fail, rather than to 
> limit their possibilities in a futile attempt to protect them.

In a majority of cases today this openness is better fostered by Github than 
"anything goes" public API.

> 
> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that 
> library had restricted my options to use it"?

I really wish Objective-C had this feature from the start.  I believe there 
would have been significant benefits to Apple's platforms and ecosystem.  The 
reasons for believing (or not believing) this have been discussed in depth so 
there isn't a need to rehash them now.

> As a matter of fact, open by default forces nobody to subclass and override, 
> so it's easy to avoid any problems caused by excessive hacking — closed by 
> default, on the other hand, has impact not only on those who believe in 
> restrictions, but on those who dislike them as well.

Actually open by default has caused some very nontrivial difficulties for 
Apple's framework maintainers.  We all pay the price for this whether we engage 
in such subclassing and overriding or not.  I find that pretty unfortunate, 
especially for those of us who do find other ways to solve our problems.

-Matthew

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 8, 2016, at 12:32 PM, John McCall  wrote:
> 
>> On Jul 8, 2016, at 8:24 AM, Matthew Johnson  wrote:
>>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  wrote:
 Am 08.07.2016 um 15:59 schrieb Matthew Johnson :
 
 
 
 Sent from my iPad
 
> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
> 
> 
> 
>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>> :
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>>>  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 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 8, 2016, at 8:24 AM, Matthew Johnson  wrote:
> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  > wrote:
>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz >> > wrote:
>>> 
 
 
 Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
 >:
 
> 
> 
> Sent from my iPad
> 
> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
> > wrote:
> 
>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>> > 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 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> 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 is dramatic, and your whole argument is flawed because you miss the imho 
most important point.
This is not only a question of "will I be able to override this tiny method of 
UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default", 
the direct impact is marginal as well — but it is a drastic change for the 
society as a whole.

Defaults matter, because they transmit a message:
Every rule and obstacle we add to Swift is a statement that says "we favor 
bureaucracy over freedom", and this will affect the community evolving around 
the language.
When you use a library in a way that wasn't anticipated by its author, you'll 
ran into issues occasionally; nonetheless, I think we should struggle for an 
open ecosystem that encourages others to experiment and fail, rather than to 
limit their possibilities in a futile attempt to protect them.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that 
library had restricted my options to use it"?
As a matter of fact, open by default forces nobody to subclass and override, so 
it's easy to avoid any problems caused by excessive hacking — closed by 
default, on the other hand, has impact not only on those who believe in 
restrictions, but on those who dislike them as well.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 7, 2016, at 4:16 PM, Goffredo Marocchi  wrote:
> 
> 
> 
> On Thu, Jul 7, 2016 at 11:15 PM, John McCall  > wrote:
> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
> > 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. :)

(Goffredo accidentally responded to me privately.  With his permission, I'm 
reposting our brief side-conversation to the list.)

> Is it just a "sweet oh so sweet" side-effect ;)?

Believe it or not, we do not actually have anything against classes! :)
 
> 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.
> 
> John.
> 
> 
> 
> Thank you for taking the time to write out this detailed defense of your 
> position. I appreciate it a lot :)!
> I think that the issue, as evidenced in this thread too, is that library 
> authors belief that sealing by default will bring ease of use AND a lot more 
> safety at the same time while I fear this may make the language more complex 
> actually.

I'm not going to deny that making classes non-subclassable by default outside 
of their module adds some complexity.  However, that additional complexity is 
subject to "progressive disclosure": it only matters to people making classes 
part of their public interface, and only when they actually want to allow 
subclasses.  Moreover, if they do want to allow subclasses, they'll try it and 
immediately run into the compiler error, which they can look up and hopefully 
find some good documentation on how to think about designing a class for 
subclassing.  That's a pretty gentle prod.

> I tend to prefer opt-in strategies, giving coders/people a better/safer 
> alternative and allowing them to choose it instead of trying to babyproof 
> everything/protect coders from themselves leaving them few ways to move out 
> of the compiler imposed restrictions. It is easier and more scalable to 
> figure out what to ban than what to allow (and assume everything we do not 
> think of in advance is bad and ought to be banned)... but now I am going too 
> much off a tangent... sorry. 

This could easily be an argument for public-by-default.  After all, 
internal-by-default is just protecting programmers from a mistake.  Some 
libraries end up with "public" written absolutely everywhere, which seems silly 
and unnecessary.  The rule promotes hiding a lot things from the user, but 
maybe those things would actually be really useful if they were exposed.  
Aren't we just babying the programmer?  Is this restriction really worth 
anything?  Maybe it would be easier to just make everything public by default 
and require programmers to explicitly hide everything they want to protect.

And you know, that's not a 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Trent Nadeau via swift-evolution]

On Tue, Jul 5, 2016 at 7:11 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> 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?
>
A strong +1 to the new default. I agree with others that having two
keywords that also conflate/imply public access is less than ideal. Having
a `public(open) class` or `public open class` would be better in my opinion.

> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
Yes.

> * Does this proposal fit well with the feel and direction of Swift?
>
Yes. Requiring extra keywords and safety at module boundaries to clarify
intent has been a philosophy toward Swift language changes.

> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
N/A

> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
Read the proposal as well as this and earlier discussions.

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



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  wrote:
> 
> 
> 
>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson :
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
>>> 
>>> 
>>> 
 Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
 :
 
 
 
 Sent from my iPad
 
> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
>  wrote:
> 
> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>  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.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

> Am 08.07.2016 um 15:59 schrieb Matthew Johnson :
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
>> 
>> 
>> 
>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>>> :
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
  wrote:
 
 n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
  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.
 
-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 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey via swift-evolution]

* What is your evaluation of the proposal?


Strong +1. I believe supporting public inheritance is the single most 
complicated thing in modern API design; thus, allowing inheritance to 
happen without explicit approval of the API designer is clearly a bad 
idea.


I'm OK with the proposed keywords (subclassable/overridable), but I 
like "open" even more.
I think "base class"/"base func" or "super class"/"super func" would 
also read well.


	* Is the problem being addressed significant enough to warrant a 
change to Swift?


Yes. This proposal helps third-party API writers avoid a major source 
of pitfalls.



* Does this proposal fit well with the feel and direction of Swift?


Absolutely. Having sensible/safe defaults for such toggles feels like a 
major feature in Swift.


	* If you have used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?


Java is a huge poster child for object oriented programming, which is 
often misunderstood to be primarily about inheritance. Still, 
collections of Java best practices invariably include strongly worded 
advice for preferring composition over inheritance, and I especially 
like the following rule:


Design and document for inheritance or else prohibit it.
-- Joshua Bloch: Effective Java. Addison-Wesley, 2001.

Even in Java, it is a bad idea to leave classes subclassable; but 
having to remember to add final is a chore.


SE-0117 takes this a step further by allowing package writers to use 
inheritance internally when it makes sense, without also having to take 
on the complications arising from allowing third-party inheritance -- 
such as having to write a reasonably complete unit test suite for 
superclass-subclass interactions. This is an interesting improvement 
over final-by-default (which I'd also support).


	* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?


I carefully read it, drank a cup of my favorite beverage to celebrate 
its existence, then I collected my thoughts.


--
Karoly
@lorentey


On 2016-07-05 23:11:17 +, Chris Lattner via swift-evolution said:


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



--
Károly
@lorentey


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
> 
> 
> 
>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>> :
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>>>  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).  

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 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Thorsten Seitz via swift-evolution]

Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
:




Sent from my iPad

On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
 wrote:


n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
 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 { ... }



-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 
 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
 wrote:

* What is your evaluation of the proposal?



Strong -1 too.



I 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

* What is your evaluation of this proposal?

A reluctant +1. I’m reluctant because I actually do love the flexibility in 
Obj-C to subclass where I feel appropriate, and feel the limitations of this 
are going to be difficult to get used to.

From what I see, however, “final” as a concept makes this more compelling. 
Being able to retroactively add final to a class is a great benefit for 
libraries, and this won’t be possible if we allow subclassing by default. 
Additionally, designing for subclassing is important and really should be 
considered at design time. I also think we need to flesh out the subclassing in 
this proposal where there are requirements to the override etc, but I agree in 
general with this concept.


* Is the problem being addressed significant enough to warrant a change to 
Swift?

There are multiple problems that this addresses. A change is definitely needed 
here to resolve them, whatever the form these changes take.


* Does this proposal fit well with the feel and direction of Swift?

Clarity at requirements for subclassing, and being more specific, seems in the 
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?

I’ve used plenty of languages with subclassing, focusing most on Obj-C. I love 
the freedom to subclass in this language, but it’s fair that this is not the 
safest practice. Obj-C seems to be the wild west for subclassing.


* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

I’ve read the proposal, followed the conversation, and was involved in the 
first discussions about this earlier in the year.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution 
>  wrote:
> 
> n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
>  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).  

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jeremy Pereira via swift-evolution]

> On 6 Jul 2016, at 00:11, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> 
> 
> 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?

-1

In general terms, the philosophy “you are not allowed to do stuff with my 
classes unless I say so” is repugnant to me. Also, the breakages in existing 
code would be more serious than usual.

The specifics:

Firstly, making a class public does not provide “two different” capabilities, 
it provides one: the class is now accessible outside the module. Using a class 
includes instantiating it, calling functions, accessing properties and also 
subclassing non final classes and methods. If you choose to make a method or 
class public you are already having to carefully consider its design perhaps 
adding guards for parameters validationetc. In this context, adding final is 
not really onerous.

Secondly, if you don’t want to go to the trouble of making your class work 
properly, you already have the option of making it final.

Thirdly, this is a huge breaking change. Not only is it a breaking change, but 
for a lot of people, the breakages will be outside of their control. Consider 
if I publish a module with a class with public methods and you subclass it in 
your code. Once this change is implemented, my code will still compile and pass 
its unit tests but your code is now broken and you are dependent on me changing 
my code to fix your code. 

Fourthly, the optimisation point is a red herring. Premature optimisation is 
the root of all evil, they say. This is premature optimisation. In any program, 
the number of methods where eliminating dynamic dispatch would provide a 
visible benefit is tiny. In those cases, you can add the word final to the 
declaration (after proper performance testing).


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

The functionality to stop people subclassing and overriding where it would be 
dangerous to do so already exists and this coupled with the serious problem of 
breaking code where the fix is outside the developer’s control makes it a very 
bad change indeed.

>   * Does this proposal fit well with the feel and direction of Swift?

No. Swift feels to me like a really nice powerful language that is easy to 
program in. Hopefully the direction of Swift is more of the same. This change 
is going the other way.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I have used many languages with classes with inheritance: Java, C++, Python, 
Objective-C, C#, Smalltalk. They all more or less follow the current Swift 
convention (in C++ you had to explicitly say if a method was virtual and that 
could be quite confusing).


>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I read the proposal and some of the other responses.


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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Pyry Jahkola via swift-evolution]

> Chris Lattner wrote:
> 
> 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
> 
>* What is your evaluation of the proposal?

+0.9. I'm positive with making the subclassability of exported classes 
explicit, but I'd reconsider the keywords proposed.

Given how the ecosystem has shaped up so far, there are very few cases where 
Swift classes could be realistically patched by subclassing and overriding. 
Instead, forking and recontributing open-source code is the better way to go. 
From my OOP in any programming languages, almost all unplanned (by library 
author) uses of subclassing have become terrible hacks that were hard to 
maintain in application code. And I don't want to imagine having to maintain a 
library that multiple users have patched by subclassing without a documentation 
of the contract between the superclass and its subclasses.

In Swift, classes seem to be most essentially about reference semantics and not 
so much about inheritance. With that, I think it's better that unlimited 
subclassing becomes a conscious choice by the library author, so that we also 
increase the probability of remembering to document what can be overridden and 
how. Originally, I would've even supported making `final` the default, but 
adding the new "sealed" inheritance mode is a very good compromise that makes 
life easier when writing application code.

Sealed classes also open a new language design opportunity where `switch` cases 
can be proven total given a sealed class type as argument.

However, I also think we shouldn't merge the the `public` modifier with the 
newly proposed keywords. From the alternatives mentioned so far, I'd give my +1 
to `public open class/func` or the spelling `public(open) class`. In this 
position, I think it'll be unambiguous given context whether `open` acts as a 
keyword or not.

Alternatively, we could reuse the `super` keyword in this context; the only 
minor issue I can see in `public super class` (besides that "superclass" should 
be written without a space) is that public unsealed classes aren't the only 
publicly visible superclasses (sealed classes are also publicly superclasses of 
their public subclasses). Well, and that the "superfunc" in `public super func` 
would be an unfamiliar term, even if it's easily taught as the kind of function 
which you should consider calling as `super.foo(...)` somewhere in an override.

The proposal also left open whether the subclassability is inherited in 
subclasses. I think it's clear that the answer is "no", and thus every subclass 
of a publicly subclassable superclass is only publicly subclassable if 
explicitly marked so.

>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes, Swift should use language design opportunities like this to statically 
encourage thoughtful library design.

>* Does this proposal fit well with the feel and direction of Swift?

Yes. It also doesn't take away the option yo make well-thought use of OOP 
better in the future, such as abstract classes.

>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A.

>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

Quick reading or a bit more.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Felipe Cypriano via swift-evolution]

To be fair and practical with the proposal it does not remove the
ability to inherit any of the UIKit classes because all Objective-C
classes are imported as "open".
 
Food for thought on inheritance-is-the-only-fix, how have we worked all
these years with C libraries like Security, Foundation, Core Graphics,
GCD, and so on if C doesn't have inheritance? My point here is not to
suggest anything other than to keep an open mind, the proposal is not
removing OO from Swift. It is definitely a non conventional approach
when compared to other languages, Kotlin is the only language with
something similar but I have never used it.
 
I have seen a lot of problems being solved by inheritance that could be
solved by composition in a way that was more reliable, testable, and
clear. When I asked why inheritance the answer is most of the time
because that is the way they know how to do things, like it was the only
tool available. I think Swift has as opportunity to increase software
quality by providing good defaults that make developers understand what
are the consequences of their choices. Maybe I'm too optimistic.
 
 
On Thu, Jul 7, 2016, at 16:01, Aditya Krishnadevan via swift-evolution wrote:
> I agree with everything James has to say here. Making classes non-
> subclassable by default is not optimal.
> A lot of fixes for small bugs in UIKit involve using a subclass that
> overrides at method or slightly modified behaviour as a temporary
> patch until the issue is fixed at the framework level.
> Preventing this *and* introducing a new keyword simply adds to the
> complexity without bringing too much to the table.
>
> Aditya Krishnadevan.
>
> On 06-Jul-2016, at 6:03 PM, James Campbell via swift-evolution  evolut...@swift.org> wrote:
>> -0.5 I think preventing subclassing is a bad idea, sometimes there
>> are bugs which can only be resolved by subclassing and this removes a
>> lot of power from app makers.
>>
>> On 6 July 2016 at 13:23, Jacopo Andrea Giola via swift-evolution > evolut...@swift.org> wrote:
>>> >   * What is your evaluation of the proposal?
>>>
>>> Unless someone can prove to me why we wouldn't need this for
>>> fixing bugs I still thing this is only a good system to hint at
>>> the developer that they shouldn't be using this class unless they
>>> have to.
>>>
>>> I could envision the compiler using the overide keyword to force
>>> the developer to acknowledge they are using a non-reccomended class
>>> like so:
>>>
>>> // This class implements a polyfill which fixes a bug in the
>>> keychain class
>>> override class PolyfillForKeychainBug: Keychain {
>>>
>>> }
>>>
>>> Without this the compiler would throw an error "Non-open class can't
>>> be overridden without `override` keyword"
>>>
>>> >   * Does this proposal fit well with the feel and direction of
>>> > Swift?
>>>
>>> It does in terms of safety but not in terms of simplicity.
>>>
>>>
>>> >   * If you have used other languages or libraries with a
>>> > similar feature, how do you feel that this proposal
>>> > compares to those?
>>>
>>> It works like Java but I never liked final
>>>
>>
>>> >   * How much effort did you put into your review? A glance, a
>>> > quick reading, or an in-depth study?
>>>
>>> I’ve read the proposal
>>>
>>> ___
>>>  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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Russ Bishop via swift-evolution]

> On Jul 5, 2016, at 4:11 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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
> 
>   * What is your evaluation of the proposal?

I think the goals are laudable but a -1 to the proposal as written. It 
conflates different things and magically having different behavior inside and 
outside the module. It seems to add a higher cognitive burden than is really 
necessary… I imagine trying to explain the behavior to a Swift newcomer and it 
never being clear on the first attempt. Subclassability is a separate concern 
from visibility, plus final doesn’t cleanly compose with this design.

IMHO It makes no sense to have a member that is public, non-virtual to external 
consumers, but overridable to internal consumers. If that’s the case, why not 
just use a protocol to completely hide the type? It just doesn’t seem like a 
common case to me.


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

C# makes members non-virtual by default, so visibility naturally controls who 
can see the type and virtual controls subclassing/overriding. Of course C# has 
protected, which controls visibility to subclassers so you can mark things as 
internal protected virtual, then the overall type as public virtual. Someone 
can still subclass but it doesn’t matter because they can’t override anything 
as all the protected override points are internal… not that it was very common!

When you’re designing things for easy subclassing I found it much more useful 
to offer protected members as the override points without letting subclassers 
override the public interface. Much less opportunity for them to screw things 
up, forget to call super, etc. In the rare case where I wanted to allow them to 
skip super’s implementation I just added that as a parameter to the protected 
member.


Russ
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Aditya Krishnadevan via swift-evolution]

I agree with everything James has to say here. Making classes
non-subclassable by default is not optimal.
A lot of fixes for small bugs in UIKit involve using a subclass that
overrides at method or slightly modified behaviour as a temporary patch
until the issue is fixed at the framework level.
Preventing this *and* introducing a new keyword simply adds to the
complexity without bringing too much to the table.

Aditya Krishnadevan.

On 06-Jul-2016, at 6:03 PM, James Campbell via swift-evolution <
swift-evolution@swift.org> wrote:

-0.5 I think preventing subclassing is a bad idea, sometimes there are bugs
which can only be resolved by subclassing and this removes a lot of power
from app makers.

On 6 July 2016 at 13:23, Jacopo Andrea Giola via swift-evolution <
swift-evolution@swift.org> wrote:

> >   * What is your evaluation of the proposal?
>
> Unless someone can prove to me why we wouldn't need this for fixing bugs I
> still thing this is only a good system to hint at the developer that they
> shouldn't be using this class unless they have to.
>
> I could envision the compiler using the overide keyword to force the
> developer to acknowledge they are using a non-reccomended class like so:
>
> // This class implements a polyfill which fixes a bug in the keychain class
> override class PolyfillForKeychainBug: Keychain {
>
> }
>
> Without this the compiler would throw an error "Non-open class can't be
> overridden without `override` keyword"
>
> >   * Does this proposal fit well with the feel and direction of Swift?
>
> ​It does in terms of safety but not in terms of simplicity.​
>
>
> >   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> ​It works like Java but I never liked final​
>
>

> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I’ve read the proposal
> ___
> 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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution 
 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.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 7, 2016, at 6:23 PM, Leonardo Pessoa via swift-evolution 
>  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.

That is a grotesque depiction.

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

If one does not have the patience to review one's own work to increase its 
quality, and would instead prefer to hand off the responsibility of finishing 
writing it to the compiler (i.e. making the compiler lock things down to avoid 
having to type "final"), perhaps a happier solution for everyone might be 
easier to keep this work private? 
I noticed in recent years that the quality of some open source code has gone 
down, seemingly under the social pressure of having to be "one of the 
kool-ones" with code hanging in the breeze on github. Personally I don't mind 
if less code makes its way to github because it is more difficult to finish it 
properly.


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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 7 juil. 2016 à 18:23, Leonardo Pessoa via swift-evolution 
>  a écrit :
> 
> 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.

If you consider Cocoa and other Apple frameworks as poorly design, then I guess 
you’re right…

Nonetheless, being able to subclass any class allowed me to solve a bunch of 
very bad memory leaks in the new NSCollectionView implementation, and made it 
usable for my project.

Thinking than you will have to work only with perfectly design libraries 
without any bug is utopian.
And thinking you can predict every usages of your library by users is short 
sighted IMHO.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

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. 

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