[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose]

> On Jul 12, 2016, at 13:44, Tino Heth <2th at gmx.de> wrote:
> 
> Thanks for the detailed answer — I didn't expect it.
> 
> 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 ;-)
> 
>> If you were writing a library, what would make you decide between “experimental” and not?
> 
> 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 ;-)
> 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…)
> 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 ;-)
> 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).

No, it was a genuine question. I don’t think I agree with your answer, but I’m glad to hear it.


> 
> Now for the remarks — they are pointless indeed, because I'm not expecting to change the mind of anyone with a well-grounded opinion
>> 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:
>> 
>> 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.
>> 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.
>> 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.
>> 4. Client X never gets a new version of Library A ever again.
> 
> Imho this is remarkable in two aspects:
> 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.
> 
> I agree that this problem is much less likely with sealed as default, but there's another one in this scenario:
> 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…
> 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 ;-)
> 
> I can't resist to add another culinary comparison to Jonathan Hull's excellent knife-analogy:
> 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?
> 
>> 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.
> Damn, maybe I should have put this in front… why make false promises at all, when you just can tell the truth?


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.

(A client might prefer that the current implementation is what’s promised, but in practice that’s almost never what either side actually wants.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160712/7829ccc8/attachment.html>