>>> Also, note, that you need only one instance of such tree in image . >>> You don't have to build this tree over and over again for each browser >>> window on screen :) >> In a way, yes. >> But then OB would basically do what the system itself should do, namely >> modeling >> packages. I would rather invest in a genuine package model in the system >> itself than >> let OB build its own persistent package model. A browser should by >> definition browse >> an existing model and not primarily create, maintain, and make persistently >> accessible a system's model. This would be like a shadow model to what the >> system >> otherwise uses, Sounds odd to me, although from a performance point of view >> it would >> make sense. >> > > Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to > model different data structures and they relations. Should we expect > from squeak/pharo to use same model? I think no. > So, even if some day we will have categories as first class objects in > system, you still will need to map them to own objects.
yes, but that won't be problematic in terms of performance anymore when we can rely on an efficient package model. The traditional system browser not showing packages (no matter whether based on OB or the old Browser class) does not need to use caching or even provide its own persistent shadow system model. Instead it just provides a view on the system model, as it should be. Because what the browser does is really simple: It traverses a tree from packages (or class cats in case of the system browser) down to methods. There shouldn't be a huge overhead if the system model provides efficient access to the entities and its sub-entities (eg. transitions from packages to class cats, to classes, to extended classes, etc.). David _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
