[swift-evolution] An Alternative for Extensibility Modifiers

[Károly Lőrentey]

> On 2016-07-12, at 13:29, Jonathan Hull <jhull at 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.

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.

-- 
Karoly
@lorentey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160712/29f961e4/attachment.html>