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

[Felipe Cypriano]

Strong +1 for me, separating access control from "open-to-subclasses" is
a great feature. Leonardo's example of why final is not enough is great.
 
My stance is that Swift should be safe by default, predictable, and the
compiler should know enough about the code to actually help me and this
proposal fits this.
 
About testability, I don't think we should downplay how to test "sealed"
classes from outside the framework. I do agree that the class should be
treated as a black box with only public APIs available, but testing how
my app is using those APIs  should be possible somehow.
 
Last but not least, I don't like the proposed subclassable/overridable,
specially because they imply public.
 
 
On Wed, Jul 6, 2016, at 12:35, Leonardo Pessoa via swift-evolution 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.
>
> 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
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/f445d1b9/attachment.html>