on Fri Jul 22 2016, Paul Cantrell <[email protected]> wrote:
>> 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. Point taken. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
