Yes I was thinking about that too for building a Preference class that
would not be called by the tools
during their execution but that would query the pragma to get
contents. Now the registration has the advantage that
you load the tools and it is registered.
Stef
On Oct 28, 2008, at 11:42 PM, Antony Blakey wrote:
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 <[EMAIL PROTECTED]>:
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
