I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system.
yes :)
If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;)
For me so far I'm pragmatic. I will push design that avoid override but I will be pragmatic because sometimes we need that.
What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...)
An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :(
Not necessarily but often it shows that we could anticipate more.
Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦
This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)).
But as I said: my brain is full. I just can't think about it now.
But I'm enjoying that :)
Me too. I worked a lot on method extension (basically the PhD of alex) and we did not find a good solution. May selector namespace but this requires a lot of work.