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.
···
On Jul 6, 2016, at 12:35 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
L
On 6 July 2016 at 16:09, Goffredo Marocchi <panajev@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@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:
* 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution