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

Sent from my iPhone On 12 Jul. 2016, at 6:19 pm, Goffredo Marocchi wrote: >> After all… you clearly don’t know about your current state, so how can you >> know how to correctly recover from it? > > This a bit of a stretch, it is often the case but not a necessary >

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

> After all… you clearly don’t know about your current state, so how can you > know how to correctly recover from it? This a bit of a stretch, it is often the case but not a necessary conclusion. Both C++ and Java have a model where it is not uncommon to recover from exceptions instead of

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

>> Safety is valued, but Swift cares (and should care!) about pragmatism as >> well… the most obvious example that comes to my mind are arrays, which have >> no safeguards that stop you from accessing elements that aren't there. > > I'm not sure I understand this point. First, a guaranteed

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

> On 2016-07-12, at 01:54, Colin Cornaby wrote: > >> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of >> things in Swift that subtly or openly discourage people from subclassing. >> How far are we from someone seriously proposing to outright

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

> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of > things in Swift that subtly or openly discourage people from subclassing. How > far are we from someone seriously proposing to outright rip inheritance out > of the language? Enough is enough. Stop with the

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

Sent from my iPhone > On 11 Jul 2016, at 09:42, Tino Heth via swift-evolution > wrote: > > >> The justification for this proposal is all about supporting the people who >> are working to design library APIs right, and about maintaining consistency >> with the

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

> The justification for this proposal is all about supporting the people who > are working to design library APIs right, and about maintaining consistency > with the design philosophy of Swift. To wit: in Swift, where there’s a > default choice, it’s the safe one; I challenge this claim:

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

> Here, I also disagree. Imagine we are talking about an open-source library on > GitHub. People will complain about the lack of sub-classability through > issues and pull-requests. This will hopefully be enough to get discussions > going on what is wrong with the API to warrant subclassing

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

Regards (From mobile) > On Jul 11, 2016, at 5:00 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Jul 10, 2016, at 9:53 PM, Paul Cantrell via swift-evolution >> wrote: >> >> >>> On Jul 10, 2016, at 8:49 PM, let var go via

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

> this thread this is completely aligned with the intention of the language, so > I think we should give it a go and stop trying to have/keep control of > everything we touch. > > L > From: Tino Heth via swift-evolution <mailto:swift-evolution@swift.org> > Sent: ‎10/‎07/‎201

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

nt: ‎10/‎07/‎2016 01:55 PM > To: swift-evolution <mailto:swift-evolution@swift.org> > Cc: Jean-Daniel Dupas <mailto:mail...@xenonium.com> > Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to > benon-subclassable publicly > > Two days ago, I challeng

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

Well stated and has pushed me into favoring the closed be default case. I favor being explicit and the default being safe (you can always unseal in a future revision if a need arises). Also as you note it won't prevent bad implementations but it will help library developers better bound their

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

> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution > wrote: > > 2. The motivation seems to be that it will force better API design. No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll

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

lution@swift.org> > Sent: ‎10/‎07/‎2016 01:55 PM > To: swift-evolution <swift-evolution@swift.org> > Cc: Jean-Daniel Dupas <mail...@xenonium.com> > Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to > benon-subclassable publicly > > Two days a

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

I think folks are going in an unprofessional direction in this thread, let bring it back to a more positive direction please. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

> You asked me to correct you and I shall: Well, in the first place, I asked how many subclasses you have to "seal" manually… may I assume that it is a low number? > You asked for an example where this feature would be needed and I've provided. No, actually you provided an example where you

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

To share some perspective, I come from working on 200k to 500k LOC systems, with the largest (aside linux kernel drivers) being ~2M loc/20,000 cpp files. I have done my share of objc coding, much of it for my own usage. My interest in swift has to do with finding a scalable solution for client

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

lution@swift.org> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-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 ca

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

> Should I assume then you want so much this proposal to be dropped you didn't > even mind to look for the example so you wouldn't have to admit this proposal > is needed? Fine, here is the whole of that example. This list has thousands of messages, this topic alone is split into at least six

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

.@xenonium.com> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-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 — whic

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

t;swift-evolution@swift.org> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by