[swift-evolution] An Alternative for Extensibility Modifiers
karoly at lorentey.hu
Tue Jul 12 07:11:13 CDT 2016
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution