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

I think you missed that I actually agree with all your points. My point was merely regarding “pre-breaking” which I thought wasn’t a relevant term. I think a far more appropriate term is “overly limiting”. We are discussing semantics, nonetheless. I actually support the idea that you should be

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

> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution > : > > If you can’t trust a developer, how could you use its library ? I guess you're getting this wrong, and maybe on purpose: Thrusting a developer is competent and tries to do a good job is on a completely different scal

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

> Le 12 juil. 2016 à 21:29, Jean-Denis Muys via swift-evolution > a écrit : > > * What is your evaluation of the proposal? > > I am strongly opposed to that proposal. I am mostly a lurker on this list, > the volume of which I cannot cope with. However, I feel this proposal is > impor

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

> I believe no programmer, least of which myself, can be trusted with the > decision to reliably decide ahead of time that this or that class cannot or > will not be subclassed. > So strong -1 for me. I just don’t get this line of reasoning. Can a programmer be trusted with determining if a typ

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

> > * What is your evaluation of the proposal? > I am strongly opposed to that proposal. I am mostly a lurker on this list, the volume of which I cannot cope with. However, I feel this proposal is important enough that I decided to invest more time than usual. So I have read carefully the

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

I completely agree, the programmer should have as much power as we can give them, even if it means allowing them to shoot themselves in the foot, because at the end of the day Swift isn¹t an academic exercise, it is a real world programming language, so it should be optimized for solving real world

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

-1. I strongly oppose this proposal and think that it adds substantial complexity to the language with introduction of yet another set of keywords that are similar to `final` and visibility modifiers, but work differently. The proposal doesn't cover the behaviour of `final` and having `final` and `

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

-1 for this proposal, but +1 for solving the issues it raises Regardless of what ends up being the defaults, I’m a very strong -1 on conflating visibility and subclassability/extendability. - Dave Sweeris > On Jul 5, 2016, at 6:11 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swif

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

+1 for the feature, +0.5 for being it the default and -1 for they syntax. I'd prefer `open`, maybe `public(open)` or probably better `public open`. I think library design is important and so this is a problem worth solving. I read the proposal and followed the discussion. -Thorsten > Am 06.07.

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

Thank you for putting your real world scenario out there too. I think you made some pragmatic points about life of application developers depending on other companies libraries and I am curious to see more debate on that point of view. On Tue, Jul 12, 2016 at 12:00 AM, Jonathan Hull via swift-evol

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

> On Jul 10, 2016, at 7:48 PM, Rod Brown wrote: > >> On 11 Jul 2016, at 12:33 PM, Jonathan Hull wrote: >> >> It is pre-breaking in that it is the exact same code that doesn’t work in >> both cases (only in the pre-breaking case, a bunch of other code also >> doesn’t work). I know it feels d

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

-1 On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://githu

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

> On Jul 11, 2016, at 11:16, Goffredo Marocchi wrote: > > So either open by default and sealed optionally or sealed by default and no > escape hatch? I think there are two separate decisions in here: - Open by default or sealed by default? - If sealed, can the seal be broken by clients? Thes

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

WebObjects is one of the frameworks I was referring to without actually naming it. After Apple stopped supporting WebObjects we have been able to fix, extend and enhance it all these years and has served us really well. It is an awesome framework. I really wish that Swift had a framework like

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

So either open by default and sealed optionally or sealed by default and no escape hatch? On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >

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

> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution > wrote: > >>> 2016/07/09 23:30、Matthew Johnson >>> > のメール： This leaves the scenario of a case where you depend on a 3rd party, closed-source library written in Swift and where y

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

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

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

> Le 11 juil. 2016 à 09:39, Tino Heth via swift-evolution > a écrit : > > >> With the existence of Swift on the server, dynamically linked, independently >> distributed frameworks will not be an Apple-only issue - this extends beyond >> Apple's OS X-based platforms towards how dynamic framew

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

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

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

Regards (From mobile) > On Jul 11, 2016, at 9:39 AM, Tino Heth via swift-evolution > wrote: > > >> With the existence of Swift on the server, dynamically linked, independently >> distributed frameworks will not be an Apple-only issue - this extends beyond >> Apple's OS X-based platforms to

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

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

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

> Am 11.07.2016 um 03:45 schrieb Rod Brown : > > That said, I actually think you have a good point however that “sealed” > should be able to be overridden, either in a patch capacity or an “unsafe” > capacity. Should this become final at a later point, you have acknowledged > you know this wil

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

> > * What is your evaluation of the proposal? > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? Extremely strong -1. I understand the performance benefit, but it’s extremely problematic if you’ve used

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

Is it more unreasonable to ask developers to seal their modules or users to unseal them? I would say Apple or third parties shipping frameworks could be asked to think about subclass ability before shipping their commercial library. Sent from my iPhone > On 11 Jul 2016, at 07:36, Rod Brown via

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

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

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

> It is *not* the case with a framework. Dynamically linked frameworks can be > changed without the app even being changed. Imagine if Apple changed UIKit > and make UINavigationController final retroactively. Your argument is true, and you choose a good example — but it's actually the only one

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

> On 11 Jul 2016, at 12:33 PM, Jonathan Hull wrote: > > It is pre-breaking in that it is the exact same code that doesn’t work in > both cases (only in the pre-breaking case, a bunch of other code also doesn’t > work). I know it feels different because it “was never possible” vs our > change

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

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

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

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

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

>> >>> 2016/07/09 23:30、Matthew Johnson >> > のメール： >>> >>> This leaves the scenario of a case where you depend on a 3rd party, >>> closed-source library written in Swift and where you cannot get (or use) a >>> fix from the vendor for some reason. This is a legiti

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

This is the case with a library. It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. UIKit internally would therefore call directly to the UINa

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

@Rod: Thank you for actually replying to the content of my post. Much appreciated. It is a trolly problem. You are arguing that pre-breaking everyone's code is better (even if causes way more trouble overall) than taking an action that breaks a few people’s code later (and thus feeling respo

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

> The problem with this is simple: you cannot retroactively "close up" an API. > I cannot add final to a class I have previously declared as non-final. I also > can seal a class which has previously been open to subclassing. Of course you can do both — it may make users angry, but so what? The e

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

I personally agree with most of your assessments. It's why I pushed so hard for "allow subclassing my default" in the first discussion of this point. The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as non-final

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

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

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

Regards (From mobile) > On Jul 10, 2016, at 7:34 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz wrote: >> >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : >>> >>> >>> >>> Sent from my iPad >>> O

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

> Am 10.07.2016 um 19:34 schrieb Matthew Johnson : > > > > Sent from my iPad > > On Jul 10, 2016, at 12:26 PM, Thorsten Seitz > wrote: > >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson >> >: >>> >>> >>> >>> Sent from my iPa

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

Sent from my iPad > On Jul 10, 2016, at 12:26 PM, Thorsten Seitz wrote: > > >> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : >> >> >> >> Sent from my iPad >> >>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: >>> >>> >>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : >>>

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

> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : > > > > Sent from my iPad > > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz > wrote: > >> >> >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >: >> >>> >>> >>> Sent from my iPa

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

Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to canc

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

This has been a very interesting and educational thread. Thanks to everyone who kindly replied to me and explained things. Here is my 2¢… > * What is your evaluation of the proposal? +0 as it stands… +1 if there could be a reliable way for us to explicitly un-seal a sealed class for those time

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

Regards (From mobile) On Jul 10, 2016, at 12:01 AM, Károly Lőrentey via swift-evolution wrote: >> On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: >> >> Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have >> the current setup by default? Why C++ x09/x11/x14 is also

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

> Am 06.07.2016 um 13:39 schrieb Matthew Johnson via swift-evolution > : > > > > Sent from my iPad > >> On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution >> wrote: >> >> Huge +1. >> >> Question about inheritance though: >> >> class A {} // Not publicly subclassable >> sub

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

> Also "subclassable class" sounds a bit redundant. In other words, I think > subclassable implies it is a class. That's a good point: There is no inherent reason that you can't inherit from a struct, and that might be possible in a future version of swift. "subclassable struct MyValue" doesn't r

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

On 2016-07-09 22:01:38 +, Károly Lőrentey via swift-evolution said: On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have the current setup by default? Why C++ x09/x11/x14 is also not making everything sealed/unsubc

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

I have been following the discussion and reading the arguments in favor and against. I think I understand both sides better now. If this proposal is accepted I hope some more thought is given to the naming. I would like to echo what others have said regarding the names. In particular I am sti

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

Reposting Károl reply on this list. On Sat, Jul 9, 2016 at 11:01 PM, Károly Lőrentey wrote: > > > On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: > > > > Why have they not "fixed" this issue with Java 6/7/8 if it is bad to > have the current setup by default? Why C++ x09/x11/x14 is also not

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

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

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

> On 2016. Jul 9., at 18:04, Tino Heth via swift-evolution > wrote: >> Of course it can be done either way. But there are significant ecosystem >> robustness advantages to making sealed the default and comparatively few >> downsides. Most libraries are open source (so can be modified directl

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

Regards (From mobile) > On Jul 9, 2016, at 7:06 PM, Jean-Daniel Dupas wrote: > > >> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution >> a écrit : >> >> >> Regards >> (From mobile) >> >>> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>>

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

Please stop saying that this proposal will bring more consideration to the design of libraries. It isn’t true. I haven’t even seen an argument for why it would be true, it is just taken for granted that it is true. As I mentioned in another post, this is structurally very different from things

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

> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution > wrote: > > >> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution >> wrote: >> >> >> >> Sent from my iPhone On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution wrote: On Jul 9, 201

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

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

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

> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution > wrote: > > > > Sent from my iPhone >> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution >> wrote: >> >>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: >>> >>> Second: >>> Do you really believe the

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

Sent from my iPhone > On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution > wrote: > >> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: >> >> Second: >> Do you really believe there will be positive impact on open-source libraries? >> My forecast is that closed by default

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

> On Jul 9, 2016, at 7:59 AM, Andre via swift-evolution > wrote: > > Thanks for the thoughtful responses, its appreciated. > >> 2016/07/09 23:30、Matthew Johnson のメール： >> >>> On Jul 9, 2016, at 8:39 AM, Andre wrote: >>> >>> Personally, Im not against sealed by default, but I think there ar

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

> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution > a écrit : > > > Regards > (From mobile) > > On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >>> On Jul 9, 2016, at 8:39 AM, Andre >> > wro

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

> Forking is desirable if your goals, needs, values, etc are substantially > different than the library author such that you do not agree on what the API > contract should look like. That's desirable in the same sense as an amputation that saves you from a deadly sepsis... I'd rather stay away

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

I fall more in Matthew side of this regarding sealed by default. On Sat, Jul 9, 2016 at 12:29 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: > > > > > >> Of course it can be done either way. But there ar

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

> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: > > >> Of course it can be done either way. But there are significant ecosystem >> robustness advantages to making sealed the default and comparatively few >> downsides. Most libraries are open source (so can be modified directly

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

Regards (From mobile) > On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jul 9, 2016, at 8:39 AM, Andre wrote: >> >> Personally, Im not against sealed by default, but I think there are cases >> where closed source libraries have certain cases where workaro

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

> Of course it can be done either way. But there are significant ecosystem > robustness advantages to making sealed the default and comparatively few > downsides. Most libraries are open source (so can be modified directly or > via PR if necessary) First: The claim about robustness sounds lik

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

Sent from my iPad > On Jul 9, 2016, at 9:59 AM, Andre wrote: > > Thanks for the thoughtful responses, its appreciated. And thank you for the dialogue and keeping an open mind on this. > >> 2016/07/09 23:30、Matthew Johnson のメール： >> >>> On Jul 9, 2016, at 8:39 AM, Andre wrote: >>> >>> Per

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

Thanks for the thoughtful responses, its appreciated. > 2016/07/09 23:30、Matthew Johnson のメール： > >> On Jul 9, 2016, at 8:39 AM, Andre mailto:pyunp...@me.com>> >> wrote: >> >> Personally, Im not against sealed by default, but I think there are cases >> where closed source libraries have certai

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

> On Jul 9, 2016, at 8:39 AM, Andre wrote: > > Personally, Im not against sealed by default, but I think there are cases > where closed source libraries have certain cases where workarounds are > necessary, and just sealing by default will prevent those cases. > > One could say, "well just u

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

When I expose an API it is to hide details behind it for the benefit of myself - as the library developer - and to benefit the library user by hiding complexity and giving them a well testable and tested contract. The "myself" benefit also benefits consumers of the library since it gives me the abi

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

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

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

Sent from my iPad > On Jul 9, 2016, at 8:37 AM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution >> wrote: >> >> What I don't get in the arguments against this capability is the fact that >> many constructs in Swift ca

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

Sent from my iPad > On Jul 9, 2016, at 8:31 AM, Goffredo Marocchi wrote: > > Ok, then I should ask you to consider what I said earlier and substitute > "final by default" with "sealed by default" and if we have this sealed > keyword not to make it the default. > Trust coders and people a bi

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

Personally, Im not against sealed by default, but I think there are cases where closed source libraries have certain cases where workarounds are necessary, and just sealing by default will prevent those cases. One could say, "well just use an open source one, or change vendors" but its not tha

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

Sent from my iPhone > On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution > wrote: > > What I don't get in the arguments against this capability is the fact that > many constructs in Swift can't be subclassed. Are we going to prevent library > developers from presenting those in the

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

Ok, then I should ask you to consider what I said earlier and substitute "final by default" with "sealed by default" and if we have this sealed keyword not to make it the default. Trust coders and people a bit more instead of resorting to more involved obligatory processes instead. Do we really

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

What I don't get in the arguments against this capability is the fact that many constructs in Swift can't be subclassed. Are we going to prevent library developers from presenting those in the public API? Your ability to subclass things when not supported by the library developer is already going t

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

Hi, > However, you *do not* want any new subclasses added as you know that is not > likely to end well. Im curious, what kind of real-world scenario would "not end well" cover? I’m genuinely curious, since Im still on the fence about this, but am willing to be convinced… if sealed by default b

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

Sent from my iPad > On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > >> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution >> wrote: >> >> Even in Java, it is a bad idea to leave classes subclassable; but having to >> remem

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

Sent from my iPhone > On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution > wrote: > > Even in Java, it is a bad idea to leave classes subclassable; but having to > remember to add final is a chore. I still think it is worth doing that chore. The fact of the matter is that Java did

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

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

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

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

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

The stories I’ve seen about things Apple’s frameworks need to deal with are another. I don’t have links handy but they shouldn’t be too hard to find for anyone interested in looking. > On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa wrote: > > I've sent one I currently have myself. Look back on t

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

I've sent one I currently have myself. Look back on the thread posts. L On 8 July 2016 at 18:14, Tino Heth via swift-evolution wrote: > > When was the last time you you thought "I really wish the author of that > library had restricted my options to use it"? > > > I really wish Objective-C had

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

>> When was the last time you you thought "I really wish the author of that >> library had restricted my options to use it"? > > I really wish Objective-C had this feature from the start. I believe there > would have been significant benefits to Apple's platforms and ecosystem. The > reasons

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

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

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

Just to relax a bit, from reading this thread I cannot help but feel a relation to Civil War. One can even say on which side everyone here would stand for real. #TeamIronMan L On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution wrote: > > > Sent from my iPad > > On Jul 8, 2016, at 12:30

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

Sent from my iPad > On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote: > > >> 1. As you point out, the majority of the surface area of idiomatic Swift >> APIs are unlikely to be impacted (value types, protocols, and final >> classes). This is very likely to apply to future Swift-na

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

Sent from my iPad > On Jul 8, 2016, at 12:32 PM, John McCall wrote: > >> On Jul 8, 2016, at 8:24 AM, Matthew Johnson wrote: >>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: Am 08.07.2016 um 15:59 schrieb Matthew Johnson : Sent from my iPad > On Jul

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

You are correct that this is not a very agile - people over processes - move. Sent from my iPhone > On 8 Jul 2016, at 18:30, Tino Heth via swift-evolution > wrote: > > >> 1. As you point out, the majority of the surface area of idiomatic Swift >> APIs are unlikely to be impacted (value type

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

> On Jul 8, 2016, at 8:24 AM, Matthew Johnson wrote: > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz > wrote: >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >: >> >>> >>> >>> Sent from my iPad >>> >>> On Jul 8, 2016, at 8:48 AM, Th

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

> 1. As you point out, the majority of the surface area of idiomatic Swift APIs > are unlikely to be impacted (value types, protocols, and final classes). > This is very likely to apply to future Swift-native APIs from Apple > regardless of the outcome of this proposal. > > 2. There is no imp

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

> On Jul 7, 2016, at 4:16 PM, Goffredo Marocchi wrote: > > > > On Thu, Jul 7, 2016 at 11:15 PM, John McCall > wrote: > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> I disagree that a stable for over

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

On Tue, Jul 5, 2016 at 7:11 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.co

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

Sent from my iPad > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: > > > >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : >> >> >> >> Sent from my iPad >> >>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: >>> >>> >>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson v

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

> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : > > > > Sent from my iPad > >> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: >> >> >> >>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>> : >>> >>> >>> >>> Sent from my iPad >>> On Jul 7, 2016, at 5

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

* What is your evaluation of the proposal? Strong +1. I believe supporting public inheritance is the single most complicated thing in modern API design; thus, allowing inheritance to happen without explicit approval of the API designer is clearly a bad idea. I'm OK with the proposed

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

Sent from my iPad > On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: > > > >> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >> : >> >> >> >> Sent from my iPad >> >>> On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution >>> wrote: >>> >>> n Jul 7, 2016,

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

Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution : Sent from my iPad On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution wrote: n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution wrote: I disagree that a stable for over 30 years of every O

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

* What is your evaluation of this proposal? A reluctant +1. I’m reluctant because I actually do love the flexibility in Obj-C to subclass where I feel appropriate, and feel the limitations of this are going to be difficult to get used to. From what I see, however, “final” as a concept makes thi

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

Sent from my iPad > On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution > wrote: > > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution > wrote: >> I disagree that a stable for over 30 years of every OOP language that I know >> is equivalent to lack of care for good l

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

> On 6 Jul 2016, at 00:11, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are so

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

> Chris Lattner wrote: > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > >

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

To be fair and practical with the proposal it does not remove the ability to inherit any of the UIKit classes because all Objective-C classes are imported as "open". Food for thought on inheritance-is-the-only-fix, how have we worked all these years with C libraries like Security, Foundation, Cor

  1   2   >