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). 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? Best regards, Tino _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
