It seems a bit like a false equivalency as notation in music is more convention on how to interpret the notes rather than something actively part of the creative process potentially.
All the programming languages are essentially reducible to if and recursion... should we just give up and move in that direction too :)? Seriously though, we ran into the issue with inheritance chains because we had this nice hammer and everything looked like a nail, Are we doing the same with POP every time we discuss something that improves or could improve OOP :)? Sent from my iPhone > On 2 Dec 2016, at 15:44, Benjamin Spratling via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
