I see where you're going with that. So it's an artifact from Java and C++, too? :)
I was recently doing a review of music notation, and one of the problems is that it has multiple ways of doing exactly the same thing. Anyone trying to read a given piece of music has to learn all of them, making the problem multiple times harder than necessary. We already have a way to enforce "you need to implement this" in Swift, and it's with protocols. Personally, I'd rather see us move in that direction. -Ben Sent from my iPhone. > On Dec 2, 2016, at 9:36 AM, Jeremy Pereira <[email protected]> > wrote: > > >> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution >> <[email protected]> wrote: >> >> I agree that there is a major problem with “subclasses must override these >> methods”. We have no capability to describe this in Swift, and frankly, it >> feels like something that ought to be enforced. It’s almost like we were >> really asked to conform to a protocol, but the protocol was a class. Maybe >> this is an artifact from previous Obj-C development? I.E. if it were >> designed in scratch in Swift it wouldn’t be a class with required overrides, >> but a protocol where every other method already had a default implementation? > > In Java and C++ you would implement this with an abstract method. i.e. a > method that has a declaration and no body. A proposal was made to introduce > these but was deferred. Reading the rationale for the decision, it looks like > the dev team were generally favourable but didn’t have time to do the > implementation, plus there were some details that needed to be nailed down. > > https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md > >> > >>> One of the simple examples would be: you need an API that requires >>> overriding? Make it accessible for ancestors only (even in protocols). >>> Despite the argument "ancestors can open it to public" (there are a lot of >>> dangerous things to do) it makes the API much more clean and hides >>> implementation complexity. Otherwise you just have to explain it in the doc >>> "please don't call this method, it's an internal" which feels wrong. >> _______________________________________________ >> 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
