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

[John McCall]

> On Jul 6, 2016, at 12:35 PM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
> Intention.
> 
> IMO, intention may lead to more secure systems (and libraries). By
> having to explicitly final everything I have to choose with parts of
> my class/library would be locked and have to worry and check if any
> public thing could be used to exploit it or make the system work in a
> way I did not intended to. Also, final will prevent anyone including
> me from extending/overriding. Defaulting to final would require from
> me to explicitly declare the open endpoints in my libraries, so I
> could explicitly open only the ones that are really intended to be
> used in that way by third-parties.
> 
> As an example, I'm working on a system which has an internal
> representation of Files and Folders using a common superclass (lets
> call it Entry). I would like for other developers to be able to create
> new entry types (not only inheriting from File) but I do not wish for
> them to extend from Folder or any of its subclasses (specialised
> folders). By using final I can prevent others from extending my Folder
> but I cannot extend it myself and thus need another mechanism for
> achieving this behaviour without bloating the Folder class with all
> its specialisations. This proposal would allow me to make my Folder
> and its subclasses publicly available/usable but would prevent others
> from subclassing and thus misusing them in ways I did not intend them
> to. The same rationale applies to methods.

I would underline this and add that the "final" workflow doesn't work very well
for methods.  You've started with a final class, but now you want to allow
subclasses, so you remove the "final"... and now you have to carefully
add it back to every method and property on your class, because the default
is non-final.  And every time you modify the class in the future, you have to
remember to think about "final" for everything you add.  Forbidding external
overrides is the safer default assumption.

The default is also better for programmers using the library, because the
class author's intent is much clearer.  I've maintained plenty of OO code where
subclassers weren't sure how they were supposed to customize the behavior
of the superclass, and so they just overrode a ton of different methods and repeated
the same logic in every place instead of using the already-defined extension
points (or asking for a new one).  Result: an unmaintainable subclass and a
superclass that can't be changed without breaking everything.

John.

> 
> L
> 
> On 6 July 2016 at 16:09, Goffredo Marocchi <panajev at gmail.com> wrote:
>> Leonardo, how is defaulting to final/sealed helping you write better libraries than having a final keyword for what you need to close instead?
>> 
>> Sent from my iPhone
>> 
>> On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> 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
>>>> 
>>>>       * What is your evaluation of the proposal?
>>> 
>>> +1. Being able to control how a class from my libraries are going to
>>> be used by third-parties could enable a better designed API with more
>>> control of how it is intended to be used. I'm just not fond of using
>>> the proposed keywords ('subclassable' and 'overridable') as they feel
>>> more like protocol or attribute names; I'd be more inclined to use the
>>> alternative 'public open' instead, or 'public(open)' as a second
>>> option.
>>> 
>>>>       * Is the problem being addressed significant enough to warrant a change to Swift?
>>> 
>>> I'd say it is significant to every language.
>>> 
>>>>       * Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes.
>>> 
>>>>       * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>> 
>>> C# uses the keyword 'virtual' to explicitly mark methods that can be
>>> overriden (not considered in the alternatives but I'm not a big fan of
>>> it).
>>> 
>>>>       * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> 
>>> I've took (a small) part on the thread discussing this proposal but
>>> followed it closely
>>> _______________________________________________
>>> 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