> On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
> I wrote that subclassability is not an important element of safety
> **independent of overriding**. If you don't allow any overriding,
> your code is always “resilient” enough to handle subclassing.
Code can make assumptions about a type having a fixed set of subclasses known
at compile time:
switch foo {
case is YinFoo:
...
case is YangFoo:
...
default:
fatalError("only two kinds of Foo known")
}
Granted, code like this is usually a sign of a flawed design. Reasonable uses
for the “fixed, known set of subtypes” pattern are rare.
Design quality questions aside, however, it is not strictly true that
preventing all member overrides guarantees that code is resilient to unexpected
subclassing.
Cheers,
Paul
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
