<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 12, 2016, at 13:44, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Thanks for the detailed answer — I didn't expect it.<br class=""><br class="">I'll re-order the original message, since you had a genuine question (to bad for me if it was just a rhetorical one :) whose answer might be more interesting than the pointless remarks afterwards ;-)<br class=""><br class=""><blockquote type="cite" class="">If you were writing a library, what would make you decide between “experimental” and not?<br class=""></blockquote><br class="">I guess I would mark everything immature/experimental/whatever on release (as long as it's not to hard to do so…), and then decide step by step wether a method should be public, overridable, private — or removed completely ;-)<br class="">Of course, there wouldn't be an universal scale, but most likely each developer/team would keep a reliable standard (some developers are very careful, some are bolder…)<br class="">If we are honest, a "sealed" that is only applied because it is the default is actually "experimental" — and in the age of open source, I don't think this should be equivalent to "you can't use this" (some conservative developers consider Swift itself to be immature ;-)<br class="">The whole concept is just a spontaneous idea, and maybe I'd come to the conclusion I actually don't like it; but as we can mark stuff as deprecated to notify users that they should stop using a certain method, it might as well be useful to annotate something as unstable to prevent certain developers start using a method (yet).<br class=""></div></div></blockquote><div><br class=""></div><div>No, it was a genuine question. I don’t think I agree with your answer, but I’m glad to hear it.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Now for the remarks — they are pointless indeed, because I'm not expecting to change the mind of anyone with a well-grounded opinion<br class=""><blockquote type="cite" class="">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:<br class=""><br class="">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.<br class="">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.<br class="">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.<br class="">4. Client X never gets a new version of Library A ever again.<br class=""></blockquote><br class="">Imho this is remarkable in two aspects:<br class="">It is the first real example I'm aware of where I see a true problem, and it "overthrows" (there might be a less dramatic word I'm not aware of) the position that "sealed" primarily solves a problem for library-authors.<br class=""><br class="">I agree that this problem is much less likely with sealed as default, but there's another one in this scenario:<br class="">Client X depends on the later-removed feature in Library A — but as this feature isn't accessible for him, he won't ever start using Library A at all…<br class="">None the less, I have to admit that I actually prefer the problem in the sealed-scenario, as it doesn't directly effect developer T, but rather pointy-haired boss Y, who just lost a potential customer ;-)<br class=""><br class="">I can't resist to add another culinary comparison to Jonathan Hull's excellent knife-analogy:<br class="">As the owner of a restaurant, would you fill your menu with food that's easy to cook to please your chef, or would you rather include food that tastes fantastic to please your customers?<br class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote>Damn, maybe I should have put this in front… why make false promises at all, when you just can tell the truth?<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">Publishing a library is a promise of <i class="">something.</i> It ought to only be promises the library author <i class="">wants</i> to make. If “the truth” is “the implementation in the current version of the library”, that’s <i class="">definitely not</i> what a library author should promise. That’s true for plenty of things, not just whether or not overriding is expected.</div><div class=""><br class=""></div><div class="">(A client might <i class="">prefer</i> that the current implementation is what’s promised, but in practice that’s almost never what either side actually wants.)</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>