If people were generally happy with having public members of open
classes overridable by default, then we certainly wouldn't need to have
a separate qualifier for that. (Although as "internal" demonstrates,
it's nice to have a formal name for such things.)
However, (1) having a default would allow API designers to define
public APIs with very little additional thought, and (2) it seems to me
we're very very far from consensus on which default would be best. I'd
like to avoid arguing even more about the theoretical merits of
choosing open vs final vs dynamic by default. (Note that there are
highly respectable app developers who honestly consider "open" much too
restricting.)
I'm enthusiastic about sealed-by-default classes, but to be honest, I
personally have no idea what default (if any) would be best for class
members. Ask me again after I've worked with the new classes for a
couple of months.
Karoly
@lorentey
On 2016-07-18 18:45:14 +0000, Nevin Brackett-Rozinsky via swift-evolution said:
Garth makes an excellent point. Károly is correct that we can already
achieve “sealed” by making a `final` member call through to an
`internal` one.
Therefore, it seem clear that “open” should only be applicable to
classes, not to members. This should simplify the proposal nicely.
Nevin
On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution
<[email protected]> wrote:
> Károly wrote: I suggest we change the proposal to remove the implicit
"sealed" level of public member overridability, and support only "open"
or "final" class members. For members, "open" should mean the opposite
of "final", with no levels in between. Member-level openness should be
entirely independent of visibility; so it should be possible to say
"internal open" to mean an internally overridable member that's not at
all visible outside the module -- the same as today's default.
What is the distinction between this approach and simply omitting the
ability to apply the “open” keyword to anything but a class?
The current behavior is (IIUC) that you cannot override a superclass’s
final method. Aside from that, you can override any other method that’s
visible to you, wherever you stand with regard to the superclass’s
origin. If there’s no sealed status for members, why is any change to
member annotations needed at all?
Garth
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
