<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 04:34, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I haven't read the whole Library Evolution document, but one important part is written right at the top:<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify; background-color: rgb(255, 255, 255);" class="">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 </span><a class="external reference" href="https://swift.org/package-manager/" style="font-weight: bold; color: rgb(85, 26, 139); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify;">Swift Package Manager</a><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify; background-color: rgb(255, 255, 255);" class="">)</span></blockquote></div><div class=""><br class=""></div><div class="">So there are compelling arguments to "seal" the Apple-libraries, and it's reasonable to enforce sealing on them.</div><div class="">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.</div><div class="">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:</div><div class="">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). </div></div></div></blockquote><div><br class=""></div><div>The binary compatibility concerns are less important, but the ability of a library author to reason about behavior is still critical. Here’s a scenario I really don’t want to see happen:</div><div><br class=""></div><div>1. Client X adds a dependency on library A, via the package manager. They override a public method in library A to get the behavior they want.</div><div>2. Library A ships an update which fixes many bugs and security issues, and happens to eliminate the internal calls to the public method A was using. That is, overriding Athat method no longer has any effect within library A; only clients see the difference.</div><div>3. The developer for client X goes to their manager and asks for time to fix the issue. The manager tells them not to update right now, but maybe after this next release.</div><div>4. Client X never gets a new version of Library A ever again.</div><div><br class=""></div><div>This hypothetical scenario happened because the client and the library had differing notions about what you could do with this particular public method. From the library point of view, this shouldn’t be a source-breaking change because they never expected it to do anything; from the client point of view, the program does a perfectly normal thing of overriding a public API and the library has capriciously broken it.</div><div><br class=""></div><div>I guess another way of saying this is that library authors avoid these miscommunications by "under-promising”, and if that “under-promising” is something that’s actually in the language instead of maybe/maybe-not being documented, then both sides are much more likely to be on the same page.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">Am 11.07.2016 um 05:38 schrieb Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div></div></blockquote><div class="">Once again a situation where we have to differentiate wether we encourage open source or not:</div><div class="">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.</div><div class="">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.</div><div class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>This is completely true, but I don’t see it as having much to do with subclassing. If a library is open source, most of your “playing with it” will be modifying the original code, not using a subclass. This is especially true given how many Swift libraries are made up of just structs, enums, and protocols. Additionally, “build for testing” will also allow subclassing sealed classes (though not final classes, since the ‘final’ is part of the semantics rather than just controlling access).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">For software that grows "organically", documentation is more useful than simple rules...</div><div class="">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.</div></div></div></blockquote><br class=""></div><div>If you were writing a library, what would make you decide between “experimental” and not?</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>