> On 2016-07-12, at 13:29, Jonathan Hull <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
