I haven't read the whole Library Evolution document, but one important part is
written right at the top:
> This model is largely not of interest to libraries that are bundled with
> their clients (distribution via source, static library, or embedded/sandboxed
> dynamic library, as used by the Swift Package Manager
> <https://swift.org/package-manager/>)
So there are compelling arguments to "seal" the Apple-libraries, and it's
reasonable to enforce sealing on them.
But if sealed is the right default for those libraries, it is not automatically
the right default for all other libraries out there, because those are
developed in a completely different manner.
So, instead making sealed the default for Swift, I believe it is much more
sound to just make it the default for the standard frameworks:
This doesn't break compatibility, it's imho more convenient for the majority,
and I guess there is enough manpower to manage the annotations for Cocoa and
other frameworks (which is tedious labor for single developers, but no issue
for a large company).
> Am 11.07.2016 um 05:38 schrieb Jordan Rose via swift-evolution
> <[email protected]>:
>
> While an overridable method may have particular preconditions and
> postconditions, it’s possible that the overrider will get that wrong, which
> means the library author can no longer reason about the behavior of their
> program.
Once again a situation where we have to differentiate wether we encourage open
source or not:
In OS, users of a library become the allies of its author — they can put stress
on his model, they can find its flaws and they can show him how to improve.
The ability to take a piece of code and start playing with it is a fantastic
trait, and this is actively discouraged by imposing limits not because they
make sense, but only because the original author didn't take the time to reason
about the status.
For software that grows "organically", documentation is more useful than simple
rules...
I like the concept of version blocks, and it could work in the other direction
as well: We could have a "experimental"-modifier that would give the library
author a way to offer hints for its clients, but leaves the final decision up
to them. This would be much more granular than a plain "final" which not only
protects those who want to stay on the safe side, but also repels the bold
developers who'd willingly help improving the code in question.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
