> On 18 Jul 2016, at 18:31, Xiaodi Wu <[email protected]> wrote:
>
> At the same time, your solution results in a lot of unnecessary boilerplate.
>
> It's an exaggeration to say that it's *a lot* of boilerplate. It's one line
> or two in the base class.
> Sure, it might be rare with methods, but don’t forget about properties! It
> makes perfect sense to have properties that should be only overridable
> internally while being accessible publicly.
>
> My first reaction here was: of course, good point! But then, on reflection,
> what properties should behave this way? Can you give an example of a property
> that makes sense to override in internal subclasses but not in external
> subclasses, but that must be accessible publicly?
>
Well, boilerplate is boilerplate. I can imagine a number of situations where
you’d need it — any time where you can some sort of logical division in your
class design, where some functionality relies on internal invariants that are
no business of the user while functionality is tweakable. At the same time,
after thinking about it for a while, I agree that such cases might be rare:
1. If your class requires a lot of sealed members, then probably there is a
better design somewhere that splits that class in multiple components.
2. If your members are overriden internally but sealed publicly, the
performance argument seems to be diminished to me — the compiler still needs to
do some sort of vtable dispatch if
the identity of the instance type is not known at compile-time.
3. I did a quick rudimentary regex through AppKit headers looking for stuff
like "((n't)|(not)).{1,15}override“ and its true that there seem to be only a
few dozens of documented methods where the documentation explicitly warns
agains overriding them. I have no idea how reliable the headers are or what
the documentation is generated from, but that appears to me to be quite strong
evidence
in support of Károly’s and others arguments.
I still think that explicit open is a better design conceptually, as it
requires one to grant per-declaration permission instead than per-declaration
prohibition, but I agree that it might be a sub optional design from the
practical standpoint because of low frequency of sealed members in practice. In
retrospect, It might be indeed worth seriously considering making ‚open‘ a
class-level annotation only. But then, there are good arguments for having an
additional ‚sealed‘ keyword for the relatively rare case where we want to
explicitly exclude a method/property from being overridable.
T._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
