> Publishing a library is a promise of something. It ought to only be promises
> the library author wants to make. If “the truth” is “the implementation in
> the current version of the library”, that’s definitely not what a library
> author should promise. That’s true for plenty of things, not just whether or
> not overriding is expected.
Correct, library users shouldn't have to puzzle over the authors intention, but
I wasn't referring to source when I wrote about truth.
A good library should strive for flexibility, and don't impose restrictions
that aren't necessary — "lack of extendability" imho is no promise an author
should want to make.
So, what if he wants to promise extendability, but just isn't sure he will be
able to stand by this promise? Instead of forcing him into lies, we could as
well accept the reality of "I'm not sure", which imho would be the most
reasonably default, as it doesn't pretend an explicit choice when there is only
uncertainty.
Jonathan Hull outlined an alternative to 0117
(http://article.gmane.org/gmane.comp.lang.swift.evolution/23761
<http://article.gmane.org/gmane.comp.lang.swift.evolution/23761>) which takes
that into account — and imho has additional benefits:
- More power (for example, UIView.drawRect and other methods that shouldn't be
called by clients could be modeled)
- Less confusion ("What's the point of subclassable and overridable? It has no
effect on the ability to subclass and override in my app at all!")
Tino_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
