On Mon, Jul 18, 2016 at 11:24 AM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:
> > > On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution < > swift-evolution@swift.org> 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. > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution