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

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

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

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

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

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

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

+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

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

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

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

+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

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

> 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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

> 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

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

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

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

* 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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