2008/10/28 Michael Roberts <[EMAIL PROTECTED]>: > I'm wondering what problem is exactly trying to be solved? From the > start of the thread it strikes me as over engineered. If tools have > to appear in the model layer, i.e. they are programmatically used then > making them pluggable requires that all different examples of the same > 'tool' respond to the same protocol. If that was the case I would > prefer that Pharo put efforts into the best tool for each category. > i'm not sure we need two debuggers or two pointer finders for example. > In specific cases if you want to resolve UI/headless issues then > perhaps there is a better way. >
Sometimes you want to stub out a tools to make them inaccessible. Or replace them with different ones. For instance, one would like to redirect Transcript output to file, or suppress debugger / browser / inspector. This can be useful for different applications, which is targeteg for users, not developers. > For general registration into menus, I consider this UI layer where > the only reference to the tool would likely be loader code to populate > the menu. In that case we already have a registration mechanism I > thought (?) and I don't see the problem with a direct class reference. > > just my 2p > > thanks > > Mike > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
