> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
