On 30 May 2013 21:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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.
ohohoho.. selector namespaces.. sounds like using nuclear weapon to get rid of cockroaches: - solution is totally inadequate for given problem (overrides are really rare) - new model could bring more problems than it solves (as nuclear weapon does ;) But i agree with Goubier that we should do something about it.. But it is what is not finished for RPackage: - make packages to be not some "ad-hoc" entity which lives parallel to system model, but a real citizen of it. Like that: - adding, removing, renaming.. anything related to methods which belongs to package should be controlled by package. Then package can reason what is allowed to do and what is not. And we should get there eventually: - Stef, you are pushing "manifests".. now imagine that manifest is not something (again) external, but the rules defined for package how to manage changes. For example, it can enforce some rules, like: no extensions allowed (so attempting to add any extension will result in error, and no method will be installed), or no removals, no uncategorized methods etc.. Or going further: run lint rule on newly compiled method, and refuse to install new method until developer can make it happy ;) -- Best regards, Igor Stasenko.