On 27.11.2013, at 01:15, Eliot Miranda <[hidden email]> wrote:
> Hi Florin, > > > On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc <[hidden email]> wrote: > Hi Frank, > > On 11/22/2013 11:09 AM, Frank Shearar wrote: > > I'd rather waste an entire class and kill Utilities, than have > > Utilities continually stick a spanner in the more important objective > > of modularity. > > > > First Utilities, then the world! > > > > frank > > I think overrides (a la VW, but they could be done even better) > > +1. I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.html for a better approach to implementation. Does it make sense to you? > I would love to see something there :) A good overriding (or shall we say method shadowing?) system would ease transitions in the trunk enormously, I would say. _Then_ we could define Some minimal packages (say the Core), which other, more sophisticated packages can override/shadow (say, Kernel, Objects[not yet existent], Collections) Best -Tobias signature.asc (1K) Download Attachment |
In reply to this post by Florin Mateoc-4
On 11/27/2013 12:21 AM, Florin Mateoc
wrote:
Just a couple of clarifications, I may have been too succinct. I would call this structural matching for projects insetad of nominal and it seems much more robust. You match more on semantics (code) rather than some convention, where the match can fail because a project bumped its version number only to add a readme. Also notice how this also makes order of project loading irrelevant, as it should be. Of course, sometimes projects do depend/build on each other, and that would be reflected in the overrides expectations - the order would be imposed, potentially automatically, by what is in the overrides and their expectations - but when they just happen to clash on some overrides, order is irrelevant. In such situations, it is enough for one project to be aware of the other one, and they can be loaded in whatever order. Say project A overrides method m from base, but is aware that sometimes people also have project B loaded, which also overrides method m. Then A can be loaded whether B is loaded or not. B can also be loaded, even if A is already loaded, since it "sees" that method m expects its own variation of method m, so it can rely on project A's variation instead (this may mean that the override itself, not just its expectations, has several incarnations, depending on what it finds already loaded) Florin |
Free forum by Nabble | Edit this page |