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

[ilya via swift-evolution]

Hello to all of the community.

** What is your evaluation of the proposal?*
+0.5
Agree on the motivation and 'public open class'
Let's discuss 'public open func' + application to dynamic runtime


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

My perspective is as follows.

We are designing a language that has a concept of classes and overrides.
Let's create a class and put some functions into it with the default
modifiers.

*Should it be possible to override those functions in the other parts of
the code?*

This is a deep question of language design. An answer will have profound
ramifications regarding the code that the compiler is allowed to produce.
It's not surprising that different languages give different answers:

- Java and Objective-C say "Yes"
- C++ and C# say "No"

Now, it doesn't look to me like it's "impossible to use libraries" in those
last two languages or that one has "less fun", or that they are
"disadvantaged on the server" because of their design choices.

What it looks like is a tradeoff. A freedom in one place is a requirement
in another place – if you say "one should be able to override those
methods", it means "a compiler should be required to perform virtual
dispatch on any call to those methods".

A smart compiler will be able to perform some guaranteed optimizations if
it knows that the calls can be devirtualized. This is a good thing, because
you can perfrom refactoring "for free".

As an example, in the scenario below Pyramid.computeVolume() can be
devirtualized even if you refactor this class as a subclass of an abstract
"Geometric-Body" class and make computeBase() overrideable.

class Pyramid {
 func computeVolume() { return computeBase() * height / 3}
 func computeBase() { return π * radius * radius }
}

This ability to extract away the code without the performance penalty and
without turning it into an unwanted override point is a benefit of the "No"
answer to the aforementioned question.

The ability to quickly design a hierarchy of classes without worrying first
about making them virtual is a benefit of the "Yes" answer to the
aforementioned question.

What would a good tradeoff then look like? It would combine the advantages
of both approaches. I believe that a default "Yes" answer within a module
and "No" across the boundary does that.

Therefore I feel like this proposal moves Swift in the right direction.

However, I'm not sure that 'open' is the right keyword for functions and
would prefer to see more discussion regarding it.

It's less clear what the benefits of non-open classes are in the dynamic
runtime, as we can't really promise that they will not be subclassed.
Incidentally, a lot of the criticism of the proposal touches the usage in
Swift of Cocoa Touch APIs. Maybe there is value in leaving things exactly
as they currently are in the Objective-C.

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

This is the first proposal I feel compelled to respond to.

Many interesting points regarding the proposal have been raised. I've spent
some time trying to read most of the thread and thought about this question
during a day. I also refreshed my memory regarding other languages, and the
design patterns of inheritance in general, e.g. here:

- https://codeblog.jonskeet.uk/2006/03/04/inheritancetax/
-
http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
- http://www.artima.com/intv/nonvirtualP.html
- http://stackoverflow.com/a/14451437/115200 (Eric Lippert)

Thank you if you got up to here,
Ilya.

On Sat, Jul 16, 2016 at 7:52 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The second review of "SE-0117: Default classes to be non-subclassable
> publicly" begins now and runs through July 22. 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?
>   

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

[David Waite via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
>   * What is your evaluation of the proposal?

+1

I don’t necessarily like the idea of sealed-by-default overridability of 
members, although I will admit it goes along well with the general philosophy 
of reducing the need for modifiers on internal API. I would prefer 
final-by-default, and the final keyword being removed.

I did not see anything within the proposal, but I assume that overridability of 
initializers was evaluated and deemed sufficient with existing mechanisms?

>   * 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?
Generally yes
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
Sure, I would say C# follows this reasonably well with its virtual keyword, 
although I don’t believe they are sealed by default at the class level

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

Followed most of comments, In-depth study

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

[swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly=2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.com=2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.

[Tal Atlas via swift-evolution]

I have no concerns intrinsically to the behavior discussed but rather to
the complexity that this brings. Creating another type of access control
and possibly keyword just adds complexity to an already fairly complex
language. I’d probably be more onboard if it was merely final by default
for that reason alone.

> Hello Swift community,
>
> The second review of "SE-0117: Default classes to be non-subclassable
publicly" begins now and runs through July 22. 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
>
>
>

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

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

[Joseph Lord via swift-evolution]

+1 I'm sold by Brent's reasoning that sealed is the only way to keep options 
open, both for any given library and for the whole Swift language. I've stayed 
quiet until now because while philosophically inclined to final by default I 
was concerned about potential complexity and confusion.

I haven't read everything on the mailing list but I've read several blog posts 
on both sides.

In terms of the necessity of subclassing it feels to me that subclassing where 
not designed for it is a similar in principle to using private APIs which may 
at times be the only way to achieve certain things but at least on iOS the App 
Store policies prevent that.

I don't have very strong views about the syntax I'm afraid but if this is 
something that could be reversed there should be an explicit version of the 
default sealed case (like internal is with for access controls).

Joseph

On Jul 19, 2016, at 8:43 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution 
>>  wrote:
>> 
>> Denial of subclassing has always been opt-in in ever other language I’ve 
>> used (C++ and Java, to name two, and Objective-C (and older C++) don’t even 
>> have that much). Sealing a class against subclassing is one thing, but not 
>> providing any kind of escape hatch, any kind of 
>> IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
>> hamstrings all users of the code. Opt-in sealing at least constrains this 
>> scenario to places where the framework writer thought it was worth adding 
>> the extra protection against horrible horribleness.
> 
> You know, one thing I haven't seen mentioned is that, just as 
> sealed-by-default preserves the options of library programmers, it also 
> preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we 
> ultimately conclude that sealed-by-default is a disaster. What can we do 
> about it? Well, we change Swift 3+n to open all classes by default. This 
> would be source- and binary-compatible with all existing code; the only 
> wrinkle is that classes compiled with a sealed-by-default compiler would 
> still be sealed. (And that's not even a problem yet, since stable ABIs are 
> not a thing yet.)
> 
> The reverse, however, is *not* true. Going from open-by-default to 
> sealed-by-default is source- and binary-incompatible. If we don't do it now, 
> we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; 
> there are good arguments that it will improve things, but there are also good 
> arguments that it will make things worse. But if we're afraid to try this 
> now, we'll never be able to try it again, and we won't know if it would have 
> worked. Whereas if we *do* try it now, we can always roll it back later.
> 
> Software quality is one of the biggest problems our profession faces. We 
> handle crushing amounts of complexity, teetering towers of abstraction, 
> intertwined code that's at the ragged edge of our ability to comprehend it. 
> Quite possibly the most urgent need in our industry is tools to help us 
> manage it.
> 
> Sealed-by-default might turn out to be a powerful tool for managing 
> complexity, helping us prevent unexpected interactions between the 
> implementation details of separate modules. Or it might not. But we ought to 
> find out. If we always take the conservative option, if we always stick to 
> the tried and true, we will never advance the state of the art, never find 
> solutions to the problems that make "all software sucks" a truism.
> 
> We need to be bold and take a chance. If it doesn't work out, we can undo it. 
> But if it does work out, we'll be better for it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 19 Jul 2016, at 15:36, Andre via swift-evolution 
>  wrote:
> 
> Agreed, and I'm ironically reminded of the old days (as a barely conscious 
> human being) where everyone was poopooing objective-c [...], interface 
> builder is weird, oh and those square brackets what are those etc etc...

Ironically we are back to the same dismissive attitude when taking about 
Objective-C now it seems lol, history does likes cycles sometimes ;).

I am in favour of Swift taking chances, but throwing away with disgust 
everything which is not the brand new hope does a major disservice to the 
achievements and productivity the previous instruments bring and the lessons 
they teach.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Steinberg via swift-evolution]

+1 to Brent’s reasoning. 
> On Jul 19, 2016, at 3:43 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution 
>>  wrote:
>> 
>> Denial of subclassing has always been opt-in in ever other language I’ve 
>> used (C++ and Java, to name two, and Objective-C (and older C++) don’t even 
>> have that much). Sealing a class against subclassing is one thing, but not 
>> providing any kind of escape hatch, any kind of 
>> IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
>> hamstrings all users of the code. Opt-in sealing at least constrains this 
>> scenario to places where the framework writer thought it was worth adding 
>> the extra protection against horrible horribleness.
> 
> You know, one thing I haven't seen mentioned is that, just as 
> sealed-by-default preserves the options of library programmers, it also 
> preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we 
> ultimately conclude that sealed-by-default is a disaster. What can we do 
> about it? Well, we change Swift 3+n to open all classes by default. This 
> would be source- and binary-compatible with all existing code; the only 
> wrinkle is that classes compiled with a sealed-by-default compiler would 
> still be sealed. (And that's not even a problem yet, since stable ABIs are 
> not a thing yet.)
> 
> The reverse, however, is *not* true. Going from open-by-default to 
> sealed-by-default is source- and binary-incompatible. If we don't do it now, 
> we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; 
> there are good arguments that it will improve things, but there are also good 
> arguments that it will make things worse. But if we're afraid to try this 
> now, we'll never be able to try it again, and we won't know if it would have 
> worked. Whereas if we *do* try it now, we can always roll it back later.
> 
> Software quality is one of the biggest problems our profession faces. We 
> handle crushing amounts of complexity, teetering towers of abstraction, 
> intertwined code that's at the ragged edge of our ability to comprehend it. 
> Quite possibly the most urgent need in our industry is tools to help us 
> manage it.
> 
> Sealed-by-default might turn out to be a powerful tool for managing 
> complexity, helping us prevent unexpected interactions between the 
> implementation details of separate modules. Or it might not. But we ought to 
> find out. If we always take the conservative option, if we always stick to 
> the tried and true, we will never advance the state of the art, never find 
> solutions to the problems that make "all software sucks" a truism.
> 
> We need to be bold and take a chance. If it doesn't work out, we can undo it. 
> But if it does work out, we'll be better for it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[James Froggatt via swift-evolution]

> On 19 Jul 2016, at 17:05, Jose Cheyo Jimenez  wrote:
> 
> 
> 
>> On Jul 19, 2016, at 4:13 AM, James Froggatt via swift-evolution 
>> > wrote:
>> 
>> Based on the discussion, I think the real danger of subclassing is 
>> unexpected behaviour - in other words, overriding methods. There doesn't 
>> seem to be a need to penalise subclasses which just add properties and extra 
>> methods based on them.
>> 
>> I'd be in favour of keeping current behaviour for classes, but having to 
>> mark methods explicitly as overrideable, virtual, open, or whatever 
>> semantics we decide upon. This seems like the safest syntax.
>> 
>> I'd also support a grouping mechanism for marking methods in this way, 
>> similar to extensions' current auto-annotation for ‘public’.
> The is a proposal waiting to be merged that seeks to disallow public 
> extensions auto-annotation. I think extensions would be better with out it. 
> 

Indeed, hence why I'm calling it a ‘grouping mechanism’ for now. If this is 
removed from extensions, I'm hoping for a more focused replacement - not so 
much because I'm a lazy typer, but rather because it supports the addition of 
this sort of granular access control, while keeping boilerplate to a minimum.

> 
>> 
>>  Begin Message  
>> Group: gmane.comp.lang.swift.evolution 
>> MsgID: <2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.com> 
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. 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
>> 
>> 
>> - End Message - 
>> ___
>> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 19, 2016, at 4:13 AM, James Froggatt via swift-evolution 
>  wrote:
> 
> Based on the discussion, I think the real danger of subclassing is unexpected 
> behaviour - in other words, overriding methods. There doesn't seem to be a 
> need to penalise subclasses which just add properties and extra methods based 
> on them.
> 
> I'd be in favour of keeping current behaviour for classes, but having to mark 
> methods explicitly as overrideable, virtual, open, or whatever semantics we 
> decide upon. This seems like the safest syntax.
> 
> I'd also support a grouping mechanism for marking methods in this way, 
> similar to extensions' current auto-annotation for ‘public’.
The is a proposal waiting to be merged that seeks to disallow public extensions 
auto-annotation. I think extensions would be better with out it. 


> 
>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID: <2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.com> 
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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
> 
> 
> - End Message - 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

2016/07/19 16:43、Brent Royal-Gordon via swift-evolution 
 のメッセージ:

>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution 
>>  wrote:
>> 
>> Denial of subclassing has always been opt-in in ever other language I’ve 
>> used (C++ and Java, to name two, and Objective-C (and older C++) don’t even 
>> have that much). Sealing a class against subclassing is one thing, but not 
>> providing any kind of escape hatch, any kind of 
>> IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
>> hamstrings all users of the code. Opt-in sealing at least constrains this 
>> scenario to places where the framework writer thought it was worth adding 
>> the extra protection against horrible horribleness.
> 
> You know, one thing I haven't seen mentioned is that, just as 
> sealed-by-default preserves the options of library programmers, it also 
> preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we 
> ultimately conclude that sealed-by-default is a disaster. What can we do 
> about it? Well, we change Swift 3+n to open all classes by default. This 
> would be source- and binary-compatible with all existing code; the only 
> wrinkle is that classes compiled with a sealed-by-default compiler would 
> still be sealed. (And that's not even a problem yet, since stable ABIs are 
> not a thing yet.)
This is exactly my thought as well, if it does end up not optimal it can always 
be changed back in a subsequent update.

> The reverse, however, is *not* true. Going from open-by-default to 
> sealed-by-default is source- and binary-incompatible. If we don't do it now, 
> we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; 
> there are good arguments that it will improve things, but there are also good 
> arguments that it will make things worse. But if we're afraid to try this 
> now, we'll never be able to try it again, and we won't know if it would have 
> worked. Whereas if we *do* try it now, we can always roll it back later.
I got the feeling that's why this is being pushed now and not swift 3.1 or 4...

> Software quality is one of the biggest problems our profession faces. We 
> handle crushing amounts of complexity, teetering towers of abstraction, 
> intertwined code that's at the ragged edge of our ability to comprehend it. 
> Quite possibly the most urgent need in our industry is tools to help us 
> manage it.
This is implicitly the reason that I changed my +0 to +1, alot of software is 
crap and it's crap because we don't get a handle on complexity, and this has a 
potential to reign some things in and bring a little discipline where it's 
needed.

I was originally very very against this, but as I thought about it I realized 
my only "real" reason at the end of the day was fear: fear of loosing certain 
flexibility, fear of loosing a tool I have used in the past, fear of change 
(again only speaking for myself) ... and really what I'm getting in return for 
that change though is the potential for some real increase in reliability (and 
maybe a lot of performance) on all sides. 

Things really teeter out of control I think because we can do all this crazy 
stuff behind the back of everything else and while this gives great flexibility 
to do some truly remarkable things,  it also piles up on top of itself and 
mucks things up... it works until it doesn't... and while the objc world is 
much more disciplined than others, my experience in the PHP/JavaScript side of 
things makes me never want to go back to that place... infinite regresses into 
over-complexity... 

> Sealed-by-default might turn out to be a powerful tool for managing 
> complexity, helping us prevent unexpected interactions between the 
> implementation details of separate modules. Or it might not. But we ought to 
> find out. If we always take the conservative option, if we always stick to 
> the tried and true, we will never advance the state of the art, never find 
> solutions to the problems that make "all software sucks" a truism.
Agreed, and I'm ironically reminded of the old days (as a barely conscious 
human being) where everyone was poopooing objective-c and why don't we just 
stick to codewarrior and metrowerks and c++... new is bad and what we had is 
just fine, interface builder is weird, oh and those square brackets what are 
those etc etc... I'm not saying this is the same thing or that arguments 
against this proposal are not merited (of course they're merited) but it's a 
trade off and I think what we would get in return would be huge and potentially 
more useful in the long run. (wow have i come full circle...)

Maybe we do need to be able to unscrew the bottle and be able to override 
something forcefully as a last resort and maybe I should have not voted a full 
+1 because I agree with others that it's an important function... 

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

[Tino Heth via swift-evolution]

> Am 19.07.2016 um 04:11 schrieb Jonathan Hull via swift-evolution 
> >:
> 
> Second, I would really like to see the methods match the open-ness or 
> final-ity of their enclosing scope by default.  Note: I also feel this way 
> about access levels, which work this way except for public… I believe they 
> should work the same way for public too (while keeping internal as the 
> default level for top-level structures).

afaics, I completely agree with your whole message, but this one is worth to be 
emphasized:
The effect of "public" should be propagated in the same way as "open"; I don't 
think there is any good reason to have two different models for similar 
concepts.

I think it would be even better to extend propagation up to module-level, and 
let the author decide what access levels are right for him — but that's most 
likely way beyond the willingness for compromise.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

Based on the discussion, I think the real danger of subclassing is unexpected 
behaviour - in other words, overriding methods. There doesn't seem to be a need 
to penalise subclasses which just add properties and extra methods based on 
them.

I'd be in favour of keeping current behaviour for classes, but having to mark 
methods explicitly as overrideable, virtual, open, or whatever semantics we 
decide upon. This seems like the safest syntax.

I'd also support a grouping mechanism for marking methods in this way, similar 
to extensions' current auto-annotation for ‘public’.

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.com> 

Hello Swift community,

The second review of "SE-0117: Default classes to be non-subclassable publicly" 
begins now and runs through July 22. 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


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

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

[Tino Heth via swift-evolution]

> Am 19.07.2016 um 09:43 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> We need to be bold and take a chance. If it doesn't work out, we can undo it. 
> But if it does work out, we'll be better for it.
It's hard for me to associate a proposal that is grounded on fear with the word 
"bold", yet the essence of the message is correct — but Imho it is another "in 
a perfect world" statement:
In reality, nobody will measure the effect of this change, and those in favor 
of the proposal might even call the absent of a horrible catastrophe a "proof" 
for their opinion.
So, what could this catastrophe actually be? Supporters of 0117 educated us 
that forking is a good thing, and that's about the worst thing I can imagine 
(exorbitant pessimism left aside)…
We won't have a "free" Swift and a "restricted" Swift to check what people 
actually prefer, and even if we had, there would be those saying that their 
opinion is the only truth, no matter what the majority thinks.

The bad effects of the proposal are no obvious danger, like a wild crocodile 
that threatens you — it is more like a swarm of mosquitos that feasts on your 
blood and dampens your mood.
I'm am convinced this change will be a source of constant annoyance, but people 
are very good at accepting constant annoyance (they have even a noticeable 
track record in accepting things that are much worse than annoyance: It took us 
hundreds of years to realize that burning old ladies with a talent for 
leechcraft might not be the smartest idea...).

Despite claims by others, this is not about proofs or facts at all, it is just 
about attitude, and attitude is hard to change. This article 
(http://martinfowler.com/bliki/DirectingAttitude.html) was a big help for me to 
understand the underlying motives which were absolutely alien to me, and 
convinced me that there is no merit in discussion anymore:
It's misfortune for our party that those who decide the default belong to the 
other camp, but that's life, and we have to accept it.

So, regarding the problem of wether subclassing and overriding should be 
discouraged, we have two contrary positions, and Swift clearly discarded the 
"enabling attitude"… for those who share this point of view, it is a 
frustrating decision after a frustrating debate on a frustrating topic, so 
please be patient with us who walk the narrow path between cynicism and 
resignation ;-)

Swift is a new language and a projection surface for those taking part in the 
discussion here, and it is unavoidable that there will be situations that are 
disappointing for parts of the community*.

- Tino

* although I think that asking an ornithologist for counsel on the choice for 
the name could have saved us from some irritation... "Cagebird" sounds nice as 
well, and it is a much better fit for the goals of of 0117, which really don't 
match with the characteristics of its eponymist ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution 
>  wrote:
> 
> Denial of subclassing has always been opt-in in ever other language I’ve used 
> (C++ and Java, to name two, and Objective-C (and older C++) don’t even have 
> that much). Sealing a class against subclassing is one thing, but not 
> providing any kind of escape hatch, any kind of 
> IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
> hamstrings all users of the code. Opt-in sealing at least constrains this 
> scenario to places where the framework writer thought it was worth adding the 
> extra protection against horrible horribleness.

You know, one thing I haven't seen mentioned is that, just as sealed-by-default 
preserves the options of library programmers, it also preserves the options of 
the language itself.

Suppose the people who think this is a huge mistake are correct, and we 
ultimately conclude that sealed-by-default is a disaster. What can we do about 
it? Well, we change Swift 3+n to open all classes by default. This would be 
source- and binary-compatible with all existing code; the only wrinkle is that 
classes compiled with a sealed-by-default compiler would still be sealed. (And 
that's not even a problem yet, since stable ABIs are not a thing yet.)

The reverse, however, is *not* true. Going from open-by-default to 
sealed-by-default is source- and binary-incompatible. If we don't do it now, we 
may never be able to do it.

That means this is our one chance to try this. The outcome is uncertain; there 
are good arguments that it will improve things, but there are also good 
arguments that it will make things worse. But if we're afraid to try this now, 
we'll never be able to try it again, and we won't know if it would have worked. 
Whereas if we *do* try it now, we can always roll it back later.

Software quality is one of the biggest problems our profession faces. We handle 
crushing amounts of complexity, teetering towers of abstraction, intertwined 
code that's at the ragged edge of our ability to comprehend it. Quite possibly 
the most urgent need in our industry is tools to help us manage it.

Sealed-by-default might turn out to be a powerful tool for managing complexity, 
helping us prevent unexpected interactions between the implementation details 
of separate modules. Or it might not. But we ought to find out. If we always 
take the conservative option, if we always stick to the tried and true, we will 
never advance the state of the art, never find solutions to the problems that 
make "all software sucks" a truism.

We need to be bold and take a chance. If it doesn't work out, we can undo it. 
But if it does work out, we'll be better for it.

-- 
Brent Royal-Gordon
Architechies

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

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

[Gwynne Raskind via swift-evolution]

> On Jul 16, 2016, at 00:52, Chris Lattner via swift-evolution 
>  wrote:
>   * What is your evaluation of the proposal?

With all respect to those who have put a lot of work into this proposal, I’m 
reluctantly and immensely against it.

The reasoning from the core team that working with vendors replaces the ability 
to subclass to work around problems simply doesn’t hold water for me. This is a 
very real and very common issue, and there are endless cases where vendors 
won’t or even *can’t* solve the problem, especially in closed-source code. And 
it’s not just a matter of GUI applications; I’ve run into the need to subclass 
(especially in order to deliver working results in reasonable time) in projects 
as low-level and open-source as LLVM.

In short, saying "filing a bug will work" isn’t good enough to justify locking 
out the ability of developers to deal with problems in vendor code. It’s simply 
not true - it’s certainly almost never been true of Apple frameworks, and even 
when it has, that doesn’t help anyone "now". (To be clear, I’m not suggesting 
Apple is unresponsive to Radars. However, I am saying that there’s no 
transparency, no confidence in getting fixes, and no hope of any kind of 
reasonable (from a local perspective) timeline for deployment of fixes.)

In a perfect world, I agree this would be the case and *then* this proposal 
would be a fantastic concept that I’d be completely behind. Unfortunately, this 
is not a perfect world and the gains in encouraging good design and cleanliness 
of applying LSP (among other things) do not make up for the burden of 
implementation time and cost on framework users.

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

Yes. But the change is too extreme and the ugly truth of the real world makes 
this proposal an inferior solution.

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

Absolutely. If not for the practical considerations, I’d love it! Conceptually 
speaking, I find it elegant, even harmonious. But again, in practice, the 
result isn’t so pretty.

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

Denial of subclassing has always been opt-in in ever other language I’ve used 
(C++ and Java, to name two, and Objective-C (and older C++) don’t even have 
that much). Sealing a class against subclassing is one thing, but not providing 
any kind of escape hatch, any kind of 
IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
hamstrings all users of the code. Opt-in sealing at least constrains this 
scenario to places where the framework writer thought it was worth adding the 
extra protection against horrible horribleness.

For example, it makes sense to seal NSSomeCryptographicInterface because you’re 
making it that much harder for something to deliberately interfere with or 
accidentally break crypto. It makes less sense to seal NSSplitViewController - 
I’d much rather Apple just said "tough noogies, your subclass breaks in this 
version because you did something unsupported" when fixing bugs!

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

I’ve been watching the discussion on this topic back and forth for some time 
now, and I read both revisions of the proposal carefully. I’m very much 
conceptually in favor of it, and I regret that I can’t stand behind it! But the 
fact remains that I think it’s a bad idea.

-- Gwynne Raskind

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

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

[Jonathan Hull via swift-evolution]

> * What is your evaluation of the proposal?
Still -1.  I think this is a big mistake.

That said, since it seems resistance is futile, I have a few changes I would 
like to recommend:

First, part of the proposal is aimed at methods which need to be public, but 
should not be subclassed (at least externally).  There is another equally 
encountered use-case where a method is intended to be subclassed (it may even 
be abstract), but it shouldn’t be called by anyone but the originating class 
(or very occasionally a subclass).  Common examples: drawRect: and 
layoutSubviews:.  If we had a protected access level, that would solve it, but 
since we aren’t moving that way either, we should have a keyword that is used 
in place of ‘open' for these cases (maybe “uncallable” or “hidden”).  We should 
solve these two together since ‘final’, ‘open’, and ‘uncallable’ are all 
mutually exclusive states.

Second, I would really like to see the methods match the open-ness or final-ity 
of their enclosing scope by default.  Note: I also feel this way about access 
levels, which work this way except for public… I believe they should work the 
same way for public too (while keeping internal as the default level for 
top-level structures).  If a class is public open, I am typically going to want 
85%+ of the methods to also be 'public open’.  Having to annotate each of them 
adds a lot of visual noise, and is fairly easy to forget to add when 
refactoring amidst that visual noise.  I already have this problem with 
‘public', so I expect it will only be worse for 'public open'.


Finally, can we talk about migration strategy?  I mean, we are about to break 
all of CocoaPods and most of GitHub.  At the very least, when migrating to 
swift 3, we should take any classes/methods which are marked public (but not 
final) and mark them public open.  That is what the authorial intent was in 
Swift 2.  This is especially true for people who went through and marked some 
of their classes/methods final (or thought about it and purposefully didn’t).  
Otherwise we are asking users of these frameworks to go in and guess the 
author’s intent by hand annotating everything while they wait for a fix.

This, more than any other change, will keep me from being able to upgrade to 
Swift 3 in a timely manner (I have to wait for my dependencies to update).  
With a migration strategy, at least I can run the updater on their code as a 
stop-gap until they have updated their frameworks.

As a framework author myself, this is a tricky update.  I have frameworks which 
work perfectly well in Swift 2, but are now unusable in Swift 3 without these 
annotations… but the annotations make them unusable in Swift 2.  I know that is 
part of the “source-breaking changes” bit, but I have been able to work around 
pretty much everything else until this.  In the cases where there is a name 
change causing issues (e.g. “Collection” vs “CollectionType”) they could just 
run the auto-updater and everything worked.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
No, I think it is premature optimization.

There is one legitimate issue of needing to subclass internally without 
allowing public subclassing.  There are workarounds, but they are workarounds.  
Still, this could be solved without changing the default.  I believe changing 
the default in this manner will create many more problems than it solves. 


> * Does this proposal fit well with the feel and direction of Swift?
No, I believe it makes Swift worse overall.  More visual noise everywhere when 
reading/writing frameworks.  

I especially think this hurts code reading, which is a hobby/habit of mine.  I 
will just run through GitHub frameworks reading the code to see how different 
authors solve problems or organize their code.  I already find having ‘public’ 
everywhere makes everything less clear/parseable and I suspect that having 
‘public open’ everywhere will be strictly worse.  I know that is a less common 
use-case, but it is something that every programmer should do (and frameworks 
are, in a way, one of the public faces of swift).


> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
We are breaking new ground here… and not in a good way.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I read the proposal and most of the (very long) discussion.

Thanks,
Jon


> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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 

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

[Amber, SimpleTouch via swift-evolution]

* What is your evaluation of the proposal?


Quoting Motivation : "The major observation here is that not all classes
make sense to subclass, and it takes real thought and design work to make a
class subclassable *well*. As such, being able to subclass a public class
should be an additional "promise" beyond the class just being
marked public."


There seems to be two questions.

   1. should a class being designed  be sealed or not?  ’final’ already
   works, changing defaults seems unnecessary.
   2. how does the class designer go about selecting what to expose for
   possible overriding in sub-classes.  I agree with the proposal.
   Selectively publishing members is a better way to think about the class
   design, and will result in clearer intent and better design.

Suggestions:

   1. leave `final` as is
   2. require explicit annotation of members for overriding. ( `default`,
   `published`, `open` )
   3. whether a class or member is public, internal, or private should have
   no bearing on number 1 or  2.
   4. if there are no `published` members, class is implicitly final.

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


As proposed the ideas are very much in line with Swift,  hopefully as
suggested even more so.


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

A moderate amount of thought and experimentation. I did not have time to
read historical discussions.


Amber

On Sat, Jul 16, 2016 at 1:52 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The second review of "SE-0117: Default classes to be non-subclassable
> publicly" begins now and runs through July 22. 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 #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 17, 2016, at 5:16 AM, Károly Lőrentey via swift-evolution 
>  wrote:
>> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution 
>>  wrote:
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. 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?
> 
> +1, with notes:
> 
> 1. The interaction of open with the dynamic keyword should be specified. Does 
> "public dynamic" imply “open”? Dynamic provides a level of flexibility beyond 
> mere subclassing, so I believe it should. Dynamic already conflicts with 
> “final”, so there is precedent for this kind of interaction in the language. 
> Note that “public dynamic” implying “open” means that we can’t have public 
> dynamic members in a public class that’s not also open. I think this 
> restriction is reasonable.

Right.  I think the right way of thinking about "dynamic" is as a fourth member 
of this category of polymorphism control modifiers: "dynamic", "open", nonopen 
(currently unspellable in the proposal), and "final".  Depending on where we 
ultimately go with "dynamic", it's *possible* that we'll want the ability to 
say "this method can be dynamically changed in-place but not overridden", 
but... frankly, I doubt we'll do that, and even if we do, it doesn't seem like 
the right default for "dynamic" alone (possibly "dynamic final").  So I think 
the answer is that "dynamic" permits overriding.

> 2. What about @objc methods? The docs say that it makes a name available but 
> doesn’t guarantee dynamic dispatch on its own; so, it looks mostly irrelevant 
> to this proposal.

Correct.  @objc just means the method is usable from Objective-C.

> 3. The problem of code migration should be addressed. For example, we might 
> want the auto-translator to automatically add open to non-final public 
> methods/properties in existing code, to make it less painful to upgrade. 
> People who simply accept the conversion results will get stuck with 
> un-audited open stuff all over their public APIs, which is not ideal. On the 
> other hand, this is no different to how their existing code behaved in Swift 
> 2, so perhaps it is the best choice.

That's a good question.  My intuition is that the philosophy of this change 
suggests that we should leave existing public classes non-open.

> 4. I don’t have a strong opinion on whether “open" should imply “public". If 
> we accept that “public dynamic” is a stronger promise than “public open", 
> then it would look strange that the former requires public, while the latter 
> doesn’t. On the other hand, “public open” is going to be much more frequently 
> used than “public dynamic”, so arguably it deserves special treatment.
> 
> 5. I was suprised by the restriction that the superclass of open classes must 
> also be open. But I don’t have a convincing usecase against it, so I guess 
> it’s fine. I like that we have the option to revisit this later.

Right.  It's fully source-compatible to allow this later.

John.

> 
> 
> For fun, here are the distinct combinations of access levels and dispatch 
> clauses for members in a "public open" class after this proposal:
> 
> public dynamic // plus “public dynamic open” if we keep it separate.
> [public] open  // assuming “open” implies “public"
> public
> public final
> [internal] dynamic
> [internal]
> [internal] final
> private dynamic
> private
> private final
> 
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> Absolutely.
>>  * Does this proposal fit well with the feel and direction of Swift?
> Yep.
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> “Don’t use public subclassing" has been my policy for years, but I have not 
> had the pleasure to use a language that helps me enforce this.
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> In-depth study broken across many short sessions.
> 
> -- 
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Dave Abrahams via swift-evolution]

on Sun Jul 17 2016, Tino Heth  wrote:

> I naturally assumed that "public" and "open" would be two separate
> concepts, as it has been expressed that orthogonality* is favored.
> But actually reading the proposal, it says:
> "open is invalid on declarations that are not also public", which imho
> not only is an unnecessary mingling of the two concepts, it also
> blocks the option to declare methods that can't be called outside the
> framework, which isn't that uncommon in Cocoa (methods like
> UIView.drawRect wouldn't show up in autocompletion lists anymore).

One point is to allow the possibility of non-public open methods in the
future, even if we know we don't have the time to design or implement
them today.

> The whole proposal is about limitation whose rationale is
> incomprehensible for many, but for this "restriction of the
> restriction", I can't see any rationale at all.
>
> - Tino
>
> * At class-level, there is afaics no orthogonality planned as well (a
> class that is abstract outside its module… might be useful as well)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

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

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

> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution 
>  wrote:
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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?

+1, with notes:

1. The interaction of open with the dynamic keyword should be specified. Does 
"public dynamic" imply “open”? Dynamic provides a level of flexibility beyond 
mere subclassing, so I believe it should. Dynamic already conflicts with 
“final”, so there is precedent for this kind of interaction in the language. 
Note that “public dynamic” implying “open” means that we can’t have public 
dynamic members in a public class that’s not also open. I think this 
restriction is reasonable.

2. What about @objc methods? The docs say that it makes a name available but 
doesn’t guarantee dynamic dispatch on its own; so, it looks mostly irrelevant 
to this proposal.

3. The problem of code migration should be addressed. For example, we might 
want the auto-translator to automatically add open to non-final public 
methods/properties in existing code, to make it less painful to upgrade. People 
who simply accept the conversion results will get stuck with un-audited open 
stuff all over their public APIs, which is not ideal. On the other hand, this 
is no different to how their existing code behaved in Swift 2, so perhaps it is 
the best choice.

4. I don’t have a strong opinion on whether “open" should imply “public". If we 
accept that “public dynamic” is a stronger promise than “public open", then it 
would look strange that the former requires public, while the latter doesn’t. 
On the other hand, “public open” is going to be much more frequently used than 
“public dynamic”, so arguably it deserves special treatment.

5. I was suprised by the restriction that the superclass of open classes must 
also be open. But I don’t have a convincing usecase against it, so I guess it’s 
fine. I like that we have the option to revisit this later.


For fun, here are the distinct combinations of access levels and dispatch 
clauses for members in a "public open" class after this proposal:

public dynamic // plus “public dynamic open” if we keep it separate.
[public] open  // assuming “open” implies “public"
public
public final
[internal] dynamic
[internal]
[internal] final
private dynamic
private
private final


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Absolutely.
>   * Does this proposal fit well with the feel and direction of Swift?
Yep.
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
“Don’t use public subclassing" has been my policy for years, but I have not had 
the pleasure to use a language that helps me enforce this.
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
In-depth study broken across many short sessions.

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

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

[Tino Heth via swift-evolution]

I naturally assumed that "public" and "open" would be two separate concepts, as 
it has been expressed that orthogonality* is favored.
But actually reading the proposal, it says:
"open is invalid on declarations that are not also public", which imho not only 
is an unnecessary mingling of the two concepts, it also blocks the option to 
declare methods that can't be called outside the framework, which isn't that 
uncommon in Cocoa (methods like UIView.drawRect wouldn't show up in 
autocompletion lists anymore).

The whole proposal is about limitation whose rationale is incomprehensible for 
many, but for this "restriction of the restriction", I can't see any rationale 
at all.

- Tino

* At class-level, there is afaics no orthogonality planned as well (a class 
that is abstract outside its module… might be useful as well)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

I naturally assumed that "public" and "open" would be two separate concepts, as 
it has been expressed that orthogonality* is favored.
But actually reading the proposal, it says:
"open is invalid on declarations that are not also public", which imho not only 
is an unnecessary mingling of the two concepts, it also blocks the option to 
declare methods that can't be called outside the framework, which isn't that 
uncommon in Cocoa (methods like UIView.drawRect wouldn't show up in 
autocompletion lists anymore).

The whole proposal is about limitation whose rationale is incomprehensible for 
many, but for this "restriction of the restriction", I can't see any rationale 
at all.

- Tino

* At class-level, there is afaics no orthogonality planned as well (a class 
that is abstract outside its module… might be useful as well)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 17, 2016, at 4:24 AM, L. Mihalkovic  
> wrote:
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. 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?
> 
> Part of a series of increasingly compelling arguments for switching other 
> languages for writting ios/osx application, provided that that is not also 
> prohibited in the various stores in the near future
> 
>>   * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> No. I'll self censor the rest as it is not flatering

The jist is that, as demonstrated by the discussions in the original thread, 
the proposal as it is worded is incomplete, paving the way to a 0111 scenario 
if rushed to approval as is. 

> 
>>   * Does this proposal fit well with the feel and direction of Swift?
> 
> Feel: not surewhat the feel of swifft is supposed to be anymore
> Direction: yes... training wheels all around, limited abilitiy to organize & 
> structure code (other key features missing for that & plenty of real life 
> examples on github to show this is actually the case)
> 
>>   * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> The bulk my professional experience has been mostly with asm x86, c, c++, 
> perl, java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and 
> recently TypeScript. None have something equivalent. I recently started 
> toying with kotlin, that looks at inheritence in a similar light, but do not 
> have enough real life experience yet to speak.
> As for TypeScript, I only recently started writing large amounts of it 
> professionally, and I am absolutely blown away: it has been the easiest 
> language to learn and become extremely productive with, thanks to the most 
> sound generic type system I have ever used (for bkgrnd, I love and makes very 
> heavy use of the java/c# generics). 
> 
>>   * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> A lot.
> 
>> 
>> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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?

Part of a series of increasingly compelling arguments for switching other 
languages for writting ios/osx application, provided that that is not also 
prohibited in the various stores in the near future

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

No. I'll self censor the rest as it is not flatering

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

Feel: not surewhat the feel of swifft is supposed to be anymore
Direction: yes... training wheels all around, limited abilitiy to organize & 
structure code (other key features missing for that & plenty of real life 
examples on github to show this is actually the case)

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

The bulk my professional experience has been mostly with asm x86, c, c++, perl, 
java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and recently 
TypeScript. None have something equivalent. I recently started toying with 
kotlin, that looks at inheritence in a similar light, but do not have enough 
real life experience yet to speak.
As for TypeScript, I only recently started writing large amounts of it 
professionally, and I am absolutely blown away: it has been the easiest 
language to learn and become extremely productive with, thanks to the most 
sound generic type system I have ever used (for bkgrnd, I love and makes very 
heavy use of the java/c# generics). 

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

A lot.

> 
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 12:59 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> * What is your evaluation of the proposal?
> 
> This is improved from the previous iteration. The code example needs 
> updating, as both instances of `open func bar()` should be `public open func 
> bar()` as outlined in the Proposed Design section.

Good catch.  I'll fix this.
 
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, mostly. There is one comment in the code example that describes a 
> restriction which does not fit with the direction of Swift. It is not the 
> main focus of the proposal but I think should be changed. Namely, the 
> proposal comments:
> 
> "[The declaration `[public] open func bar()` inside a class not marked 
> `open`] raises a compilation error: a method can't be marked `open` if the 
> class it belongs to can't be subclassed."
> 
> This is discordant with the direction resolved by the core team in the 
> SE-0025 revisions, where it was stated with regard to access modifiers:
> 
> "The compiler should not warn when a broader level of access control is used 
> within a type with more restrictive access, such as `internal` within a 
> `private` type. This allows the owner of the type to design the access they 
> would use were they to make the type more widely accessible."
> 
> Applying the same rationale here would suggest that the compiler should not 
> raise an error if a method is marked `open` inside a non-`open` type, in 
> order to allow the owner of the type to design as though to make it 
> subclassable without actually having to do so.

That's true.  We'll consider this.

John.

> 
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> Yes, I've used OOP in other languages. As discussed, this approach is 
> different from that taken by many of those but is a deliberate step.
>  
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> Followed the discussion, read proposal carefully.
>  
> 
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 9:05 AM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> +1 as before but I do have concerns
> 
>   * Why do open classes need to have also have open superclasses?

I talk about this in the proposal; this is a possible avenue of future 
extension.  I wanted to keep this proposal small, and requiring the whole 
hierarchy to be open avoids a number of design problems.
 
>   * I don’t think sealed methods/properties as default is the right 
> default. 
>   * If the default was open for methods/properties, then do we really 
> need the sealed keyword? Could’t we just use final for that?

There is no "sealed" keyword in the proposal.

Since we're naming open "open", if we need a reverse, we would probably use 
"closed" or "nonopen" for it.  "sealed" is a common term for this kind of 
feature, and it's the one we've been using in this discussion, but 
unfortunately "sealed" is not a natural opposite of "open".

John.

> 
>>  * 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?
> 
> Requiring super classes to also be Open seems wrong. 
> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 
> 
> We already have to mark all public methods/properties as public, if I need 
> something not the be overridable then I can just use final. This would work 
> the same across all classes. 
> 
> If I was a framework author that initially just had a library that was sealed 
> but then somebody asked me to make it open; All I would want to do is add 
> open to the class only, I would not want to spend the time to go back an add 
> open to all public methods/properties specially if I am already using final. 
> I think having method/properties open by default is the best compromised. I 
> can see framework authors switching a class to be open and expecting that 
> everything in the class in open and if they don’t open any methods, then what 
> possible use is a subclass than an extension could not provide? I think that 
> is an overreach to make the framework author have to add open to every public 
> method in addition to having to open every super class. As a framework author 
> if I think my clients could use subclassing, all I want to do is flip a 
> switch on the classes that I want to make subclass able  and then just push a 
> new version. As a framework user I want to be able to tell my framework 
> author “can you just add open to classes abs and deca etc.” I think it is 
> more likely that I will get my request if it is easy vs it the framework 
> author needs to touch every class in the hierarchy. 
> 
> 
>>  * 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?
> 
> reviewed previously and followed the update. 
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 12:33 AM, Taras Zakharko via swift-evolution 
>  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> +1. Looks much better than the previous version and makes a lot of sense to 
> me. 
> 
> A quick clarification question (I didn’t find any mention of this in the 
> proposal, but I might have missed it): what happens if a class is declared 
> open, but does not contain any open member declarations? Is this legal? 

Yes.  Subclasses can extend the API of the class and add new properties, but 
they can't modify the core behavior of the superclass.  That's not an 
implausible class design, especially as a first step, since it would still be 
source/binary-compatible to make a method open in a later release.

John.

> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Most likely
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> A quick reading. I was also following the previous discussion. 
> 
> 
>> On 16 Jul 2016, at 07:52, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. 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?
>>  * 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 16, 2016, at 9:18 AM, Taras Zakharko  wrote:
> 
> 
>> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution 
>> > wrote:
>> 
>> I agree with Kevin Ballard on being open by default for methods/ properties 
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
>> 
>> 
>> If we are open by default for methods/properties then we could simplify 
>> things by just using final for methods that need to be sealed; I don’t see 
>> the need to have sealed methods/properties outside of the module ONLY. 
> 
> The proposal (and additional comments) explain this point fairly well. 
> Usually, it makes sense to be overridable only for few select members — and 
> compiler can’t easily figure out which entry points these are as the API 
> invariants are not explicit. By making members sealed by default, the API 
> contracts are made more clear.  Second (and a very important reason) is 
> performance — if everything is open by default, the compiler can’t 
> devirtualize property accessors even though it would be appropriate most of 
> the time. The compiler can infer the ‚final‘ status of definitions within a 
> module easily and optimise accordingly, which wot work if these definitions 
> can be overridden externally. To put it differently, its much easier for the 
> compiler to determine what can be safely considered final than what can be 
> safely considered sealed. The design choices in the proposal follow naturally 
> from these considerations. 

The compiler is welcome to optimize my sealed classes but once I slap `open` on 
the class, I am telling the compiler that I am not interested in the automatic 
optimizations imo.

> 
> The final keyword still has its use, although I think its utility will be 
> somewhat diminished after this proposal. You can still use it for things that 
> can’t be overridden internally. Like classes that are intended only to be 
> used as ‚structs  with reference semantics’. 
struct with reference semantics is what sealed classes are, but once I make the 
class open, i’d like for it to act like a regular subclassable class.


> 
> — T
> 
> 
> 

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

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

[Taras Zakharko via swift-evolution]

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 

The proposal (and additional comments) explain this point fairly well. Usually, 
it makes sense to be overridable only for few select members — and compiler 
can’t easily figure out which entry points these are as the API invariants are 
not explicit. By making members sealed by default, the API contracts are made 
more clear.  Second (and a very important reason) is performance — if 
everything is open by default, the compiler can’t devirtualize property 
accessors even though it would be appropriate most of the time. The compiler 
can infer the ‚final‘ status of definitions within a module easily and optimise 
accordingly, which wot work if these definitions can be overridden externally. 
To put it differently, its much easier for the compiler to determine what can 
be safely considered final than what can be safely considered sealed. The 
design choices in the proposal follow naturally from these considerations. 

The final keyword still has its use, although I think its utility will be 
somewhat diminished after this proposal. You can still use it for things that 
can’t be overridden internally. Like classes that are intended only to be used 
as ‚structs  with reference semantics‘. 

— T



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

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

[Jean-Daniel Dupas via swift-evolution]

> Le 16 juil. 2016 à 18:05, Jose Cheyo Jimenez via swift-evolution 
>  a écrit :
> 
>>  * What is your evaluation of the proposal?
> 
> +1 as before but I do have concerns
> 
>   * Why do open classes need to have also have open superclasses? 
>   * I don’t think sealed methods/properties as default is the right 
> default. 
>   * If the default was open for methods/properties, then do we really 
> need the sealed keyword? Could’t we just use final for that?
> 
>>  * 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?
> 
> Requiring super classes to also be Open seems wrong. 

> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 
> 
> We already have to mark all public methods/properties as public, if I need 
> something not the be overridable then I can just use final. This would work 
> the same across all classes. 
> 
> If I was a framework author that initially just had a library that was sealed 
> but then somebody asked me to make it open; All I would want to do is add 
> open to the class only, I would not want to spend the time to go back an add 
> open to all public methods/properties specially if I am already using final. 
> I think having method/properties open by default is the best compromised. I 
> can see framework authors switching a class to be open and expecting that 
> everything in the class in open and if they don’t open any methods, then what 
> possible use is a subclass than an extension could not provide?

Extensions do not support stored properties (yet?). Subclasses do. That said, I 
agree that having an open class without any open member does not has much 
benefit, but I’m sure we can find a valid use case for such class.

> I think that is an overreach to make the framework author have to add open to 
> every public method in addition to having to open every super class. As a 
> framework author if I think my clients could use subclassing, all I want to 
> do is flip a switch on the classes that I want to make subclass able  and 
> then just push a new version. As a framework user I want to be able to tell 
> my framework author “can you just add open to classes abs and deca etc.” I 
> think it is more likely that I will get my request if it is easy vs it the 
> framework author needs to touch every class in the hierarchy. 
> 
> 
>>  * 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?
> 
> reviewed previously and followed the update. 
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

>   * What is your evaluation of the proposal?

+1 as before but I do have concerns

* Why do open classes need to have also have open superclasses? 
* I don’t think sealed methods/properties as default is the right 
default. 
* If the default was open for methods/properties, then do we really 
need the sealed keyword? Could’t we just use final for that?

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

Requiring super classes to also be Open seems wrong. 

I agree with Kevin Ballard on being open by default for methods/ properties 
http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 


If we are open by default for methods/properties then we could simplify things 
by just using final for methods that need to be sealed; I don’t see the need to 
have sealed methods/properties outside of the module ONLY. 

We already have to mark all public methods/properties as public, if I need 
something not the be overridable then I can just use final. This would work the 
same across all classes. 

If I was a framework author that initially just had a library that was sealed 
but then somebody asked me to make it open; All I would want to do is add open 
to the class only, I would not want to spend the time to go back an add open to 
all public methods/properties specially if I am already using final. I think 
having method/properties open by default is the best compromised. I can see 
framework authors switching a class to be open and expecting that everything in 
the class in open and if they don’t open any methods, then what possible use is 
a subclass than an extension could not provide? I think that is an overreach to 
make the framework author have to add open to every public method in addition 
to having to open every super class. As a framework author if I think my 
clients could use subclassing, all I want to do is flip a switch on the classes 
that I want to make subclass able  and then just push a new version. As a 
framework user I want to be able to tell my framework author “can you just add 
open to classes abs and deca etc.” I think it is more likely that I will get my 
request if it is easy vs it the framework author needs to touch every class in 
the hierarchy. 


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

reviewed previously and followed the update. 

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

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

[Andre via swift-evolution]

> 2016/07/16 14:52、Chris Lattner via swift-evolution 
>  のメール：
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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?
+1 for the improved keywords and purgatory for objc imported modules.

This is much cleaner than the previous proposal, and cant wait to actually get 
to use this (as a framework author it literally makes me giddy).

Like others, I slightly wonder what will happen in The Real World™ (as a 
framework consumer) but if things end up too restrictive, it can always be 
changed down the road I would expect…?

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

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
This seems closer to Kotlin; not that I am much of a user of that language so 
maybe I am unqualified to say, but I think its nice to align with a good design 
that exists elsewhere… 
Objc is of course the exact opposite of this, so it remains to be seen what the 
effect will be in this community...

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
Been following this intensely since last year’s initial discussion, finally 
came out of the shadows to comment when it came up for review, and have been 
weighing and listening to arguments for and against; my only "against" feelings 
came about as a consumer of APIs not as a writer, so I want to make sure its 
apparent that any negatives I had in the past were from that perspective; I 
very much support the spirit of this proposal and appreciate those that took 
time to explain and assuage those concerns! What an amazing process this is. ^o^

---

One thing in the proposal:
The superclass of an open class must be open. . These are conservative 
restrictions that reduce the scope of this proposal; it will be possible to 
revisit them in a later proposal.
Yes, maybe its an anit-pattern, but I definitely have made many private parent 
classes and have the child public… the above would mean that I cant do that, as 
open needs public… it would definitely be appreciated if that is revisited or 
at least the reasoning (e.g we really shouldn't be making subclasses of private 
superclasses public because XYZABC etc).

---

Thanks!!


> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

> * What is your evaluation of the proposal?
>

This is improved from the previous iteration. The code example needs
updating, as both instances of `open func bar()` should be `public open
func bar()` as outlined in the Proposed Design section.


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

Yes, mostly. There is one comment in the code example that describes a
restriction which does not fit with the direction of Swift. It is not the
main focus of the proposal but I think should be changed. Namely, the
proposal comments:

"[The declaration `[public] open func bar()` inside a class not marked
`open`] raises a compilation error: a method can't be marked `open` if the
class it belongs to can't be subclassed."

This is discordant with the direction resolved by the core team in the
SE-0025 revisions, where it was stated with regard to access modifiers:

"The compiler should not warn when a broader level of access control is
used within a type with more restrictive access, such as `internal` within
a `private` type. This allows the owner of the type to design the access
they would use were they to make the type more widely accessible."

Applying the same rationale here would suggest that the compiler should not
raise an error if a method is marked `open` inside a non-`open` type, in
order to allow the owner of the type to design as though to make it
subclassable without actually having to do so.

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

Yes, I've used OOP in other languages. As discussed, this approach is
different from that taken by many of those but is a deliberate step.


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

Followed the discussion, read proposal carefully.


>
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1. Looks much better than the previous version and makes a lot of sense to me. 

A quick clarification question (I didn’t find any mention of this in the 
proposal, but I might have missed it): what happens if a class is declared 
open, but does not contain any open member declarations? Is this legal? 

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

Most likely

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

Yes

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

A quick reading. I was also following the previous discussion. 


> On 16 Jul 2016, at 07:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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?
>   * 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

Review link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md


* What is your evaluation of the proposal?
+1 for the implementation. +0.5 for the concept. I think this is a clean interface for 
what open should be, and am glad at the simplification. This seems very 
"Swifty", and much better than the first proposal. I'm concerned that this may 
be over-limiting developers, and while everything looks great in theory, I am concerned 
that this may not be a good decision for real-world development. That said, I also think 
there are real wins in the ability to at a later date finalise a class for performance 
reasons, and provides clear structure for how a subclass is designed be used.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
I think that sorting out our inheritance story for public frameworks is 
important if we are going to start seeing public Swift Frameworks in the wild 
more often.

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

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I haven't. I've used Obj-C a lot. The ability to fix some issues with patching 
leads me to be concerned that we are overly restricting things here.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I've been following the threads since this discussion started months back, in 
discussions recently over it, and have read thoroughly both reviews.

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

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

[Chris Lattner via swift-evolution]

Hello Swift community,

The second review of "SE-0117: Default classes to be non-subclassable publicly" 
begins now and runs through July 22. 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