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

[Leonardo Pessoa]

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.

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