[swift-evolution] An Alternative for Extensibility Modifiers

Jonathan Hull jhull at gbis.com
Tue Jul 12 06:29:00 CDT 2016


> It seems to me adding such an escape hatch makes the entire point of 
> the proposal moot.
What was the point of the proposal to you then?  This proposal makes several things possible that are not currently possible (or are at least not easy) in Swift.  For example, this lets you create subclasses inside your module, but still mark the class as final externally.  It also allows you to declare something final without an escape hatch if you so desire.

> If I say a class I define is internal or private, you have no business 
> poking at it from an external module; if I say my class is sealed or 
> final, you have no business subclassing it from an external module. 
> Swift provides no escape hatch that exposes internal components of a 
> module; I don't see why subclassibility requirements should be treated 
> otherwise.
You have the option of marking something as final if you want that guarantee to hold.  What we are talking about here with ‘sealed’ and the escape hatch is the case where you didn’t actually say anything.  You haven’t chosen Open or Final.  In this case, subclassing is discouraged, but still allowed (with the caller acknowledging and taking responsibility that the code they are writing is brittle).

I have written at length in other posts as to why this is necessary with real world code.
> Note that most popular OOP languages provide well-known patterns for 
> creating sealed but public classes, where only the author is able to 
> create subclasses. These patterns typically involve hiding class 
> constructors from external modules. If Swift was changed to support 
> sealed classes the same way, would you then propose a language feature 
> to defeat access modifiers?
All I will say is that I avoid using those languages as much as possible.  It is a separate topic, but in my opinion/experience languages which encourage too much planning/architecture lead to complicated programming structures (as an effort to work around limitations within the rules) and nothing of worth actually ends up getting accomplished.  Give me smalltalk or objC any day.

Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160712/0bd22de8/attachment.html>


More information about the swift-evolution mailing list