IMO discovery is a preferable model to registration, using either pragmas or pragma-like constructs. In Commando I do this: createCommands LSDCommando thisMethodReturnsAListOfCommands. .... and commandStructureTransformers LSDCommando thisMethodReturnsAListOfCommandTransformers. ... where the thisMethod... methods are empty. To collect all the methods that generate commands I do a senders-of-XXX-in-descendents-of-Class- that-have-an-LSDYYY-reference search. You could do more sophisticated filter after the search by bytecode analysis. One benefit of discovery is that (IMO) reuse is conceptually easier because (in the case you are talking about in this thread) the concept of 'being-a-command' is separated from 'in-the-world-menu'. Squeak has pragmas now, which people might prefer to traditional reflection. Personally I don't. On 29/10/2008, at 8:49 AM, Stéphane Ducasse wrote:
I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too.
Stef
On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote:
2008/10/28 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution.
The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.)
I think, it would be nicer, instead of use a predefined methods, use a dictionary in a form 'tool name'->class and DNU pattern which then can respond with proper class when you send message like:
Smalltalk tools browser
here , a 'Smalltalk tools' should return a registry , and then registry in #doesNotUnderstand: should lookup a dictionary by #browser key.
Also, if you want to add new, or replace old tool you just write:
Smalltalk tools register: Workspace name: #workspace Smalltalk tools register: Transcript name: #transcriptWindow ...etc...
as well as remove: Smalltalk tools remove: #workspace
With this approach, the number/kinds of tools is arbitrary. They can be freely replaced at any moment without subclassing or writing methods. In vanilla image, we need only a single method, which can populate a default tool set. Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or 'SmalltalkImage tools' is much more elegant.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis