An Alternative for Extensibility Modifiers

Evolution Discussion
1

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

2

There is truly nothing wrong with preferring the Objective-C/Smalltalk/Ruby/Python/JavaScript class of languages to the Java/C++/C#/Rust/Go camp. Most reasonable people would say that lots of worth has been accomplished in each of them. Also, most people would say that too little planning/architecture can be just as damaging (or more) as too much.

But Swift is obviously in the second camp, and has been since 1.0.

I doubt there is a good middle ground between the two approaches; they seem to be mutually incompatible. Most concessions to “loose" languages in a “strict” language feel out of place, and vice versa.

Swift does provide an important concession to Objective-C in its @objc attribute, whose interaction with final/sealed classes could perhaps be tweaked to achive what you want.

···

On 2016-07-12, at 13:29, Jonathan Hull <jhull@gbis.com> wrote:

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.

--
Karoly
@lorentey