> On Jul 18, 2016, at 9:31 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Mon, Jul 18, 2016 at 11:24 AM, Taras Zakharko via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > I see no drawback to this pattern; it is quite clear and simple. Therefore, > > in the interest of keeping the language free of needless complexity, I > > suggest we change the proposal to remove the implicit "sealed" level of > > public member overridability, and support only "open" or "final" class > > members. > > > At the same time, your solution results in a lot of unnecessary boilerplate. > > It's an exaggeration to say that it's *a lot* of boilerplate. It's one line > or two in the base class.
The basic effect of Károly's counter-proposal is that every public member of an open class has to be marked either "open" or "final". That's boilerplate. I think you and Károly are evaluating the addition of non-open methods as if they were being added primarily to increase expressive capabilities. They do marginally increase expressiveness, but I agree that it's not a common situation to explicitly want. However, neither are non-open classes. The goal here is not to create new expressive power, it's to establish a comprehensible intermediate position that's acceptable as a default so that publicizing an API doesn't require so much annotation and bookkeeping. Otherwise, programmers are forced to immediately decide between over-promising (by making the method publicly overridable) or breaking their own code (if they have internal overrides). Furthermore, I don't agree that non-open methods add significant new complexity. For clients of a library, a non-open method is final; there are no semantically-detectable differences (ignoring covariant overrides). Within a library, non-open methods remove the need for some unnecessary bookkeeping. And just on a conceptual level, the analogy to class behavior is quite simple. John. > > Sure, it might be rare with methods, but don’t forget about properties! It > makes perfect sense to have properties that should be only overridable > internally while being accessible publicly. > > My first reaction here was: of course, good point! But then, on reflection, > what properties should behave this way? Can you give an example of a property > that makes sense to override in internal subclasses but not in external > subclasses, but that must be accessible publicly? > > Imagine adding that boilerplate to every such property.. > > On balance, I think the number of `open` annotations would far exceed the > amount of this boilerplate. I'm not convinced it is even a mildly common use > case. > > > Basically, if we do it your way, then it won’t be long that someone submits a > proposal for a keyword for synthesising the boilerplate, which more or less > brings us back to square one. > > T. > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
