[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth]

> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution <swift-evolution at swift.org>:
> 
> If you can’t trust a developer, how could you use its library ?
I guess you're getting this wrong, and maybe on purpose:
Thrusting a developer is competent and tries to do a good job is on a completely different scale than the faith that someone foresees the future and writes code without any errors.

> Using third-party code involve some kind of trusting, as you would have to trust the developer to write reliable and efficient code, which is IMHO, far more important than knowing if the developer carefully choose what can be subclasses or not.
Very true — so wouldn't it better to concentrate on topics that help developers write this code, instead of building a bureaucracy that makes coding harder?

> And when you encounter a library where the dev choose to allow subclassing, you will have far more trust than the code was design to be subclassed.
I have the impression that many supporters of the proposal would love to have the power to not only change a tiny part of the language, but all the people using it... luckily, this isn't true, and this would be a false feeling of security:
Even if you punish them, some developers will value the freedom of choice more than the tiny slight risk of harming someone who uses this liberty — and even the biggest bureaucrats won't get their inheritance-model right all the time...

> Some design patterns work better with subclassing than with protocol or delegation. So I’m confident than library developers will ‘open’ there classes if needed.

Would you allow others to put you in a cage, as long as they will open it if needed?
I wouldn't want that, even if that cage offered some protection.

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/322f4a41/attachment.html>