2008/10/28 Michael Roberts <mike@mjr104.co.uk>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.