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
>
> 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
>> 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
> 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
> - 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
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
> 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:
> 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
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
> 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
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
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
> 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
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
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
> 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
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
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
> 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
.@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
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
21 matches
Mail list logo