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

[Leonardo Pessoa]

What you said back then lead me to understand you did not get the
difference. Forgive me if it wasn't the case but I've also seen it
happen more than once in this list, hence the repeatition. I also
understand that there are other ways to implement the same behaviour
we want without sealed by default but I wouldn't call a lot of
boilerplate "elegant".

The examples you asked for have already been provided a few times in
this thread and the previous and trying to disqualify them won't make
them go away. And I didn't ask you to prove there is no valid use case
for this; I asked you to give a good technical reason (one that is not
"being able to fix someone elses' code") to keep it as is today, which
is different.

I'm placing my view here that by default would have to mean
non-propagating open to subclasses unless the one writing the subclass
means it too by explicitly keeping it open. To me, meaning (intention)
is the keyword here. I believe there is no need to really introduce a
new keyword for sealed but it will be necessary should open propagates
in order to allow a library extending from another library to re-seal
methods. This is inconsistent with sealed **by default** (that is,
unless stated otherwise).

The core team has already said that this is on, so I think it is a
waste of time to continue trying to disqualify the proposal
altogether. We have to focus on the issues the core team pointed out
that needed solving. Just like David, I also didn't like fileprivate
but I'm not here trying to disqualify it (how long has it been,
actually?). I also liked to know that there are other examples of
languages that follow this model of sealed by default and they work,
even though most of them are little known languages. It's a model to
work with and every language has one; we're just changing Swift's.

L


On 20 July 2016 at 16:05, Michael Peternell <michael.peternell at gmx.at> wrote:
>
>> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution <swift-evolution at swift.org>:
>>
>> Sealed methods can be overriden inside the defined module/library but
>> not outside. Same benefit of classes.
>
> Interesting how the supporters of the proposal seem to imply that the opponents of the proposal don't get the difference between sealed and final. This has happened more than once here.
>
> I know that sealed and final are different, but still I think that sealed has no proper use case that cannot be achieved with final as well (and more elegantly so). Interestingly, no one has yet created a simple example with more than 60 lines of code that demonstrates the use of sealed, and why it is better than final. (Not counting contrived examples with class names like `SomeClass` and similar method names.) I guess that you will not find such a use-case. But who should prove this? Do the opponents of the proposal have to prove that there is no single good use case? Or should the supporters at least demonstrate 2 good use cases (again, non-contrived examples with more than 60 lines of code.) If the supporters are not able to make some good example code with sealed/open, the library developers of the future will not either. I agree with everything Garth said below. I hope for a miracle that the core team will see soon that SE-0117 should be deallocated fast ;) I'm sure we will all learn this in a year or two, when there will be experience with the sealed implementation.
>
> -Michael
>
>>
>> L
>>
>>
>> On 18 July 2016 at 16:32, Garth Snyder via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>>> Nevin/Garth, please remember final and sealed are two different
>>>> concepts: final prevents anyone from subclassing/overriding while
>>>> sealed prevents from subclassing/overriding *outside* the module they
>>>> are declared. Thus final is not the same as sealed.
>>>
>>> No, of course it isn’t. I could well be misguided, but I don’t think I’m disoriented. :-)
>>>
>>> Ultimately, the question is whether sealed methods offer any additional utility or advantage beyond that of sealed classes plus final. The existence of “final” is certainly relevant, as it already provides some, but not all, of the features of method-level sealing.
>>>
>>> I’d still like to see a really solid use case that requires the full semantics of sealing at the method level.
>>>
>>> Garth
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>