> 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.
