Proposal for implementing services in squeak, need feedback
Avi Bryant
avi at beta4.com
Fri Apr 16 20:06:10 UTC 2004
Romain,
I've finally gotten around to looking at your Services code, and I have
one overriding comment, which is that although I like the model, the
interface to it is too implicit - too magic. The best example is this,
which I didn't understand when I first read it but do now:
> Now you must be wondering how to fetch the parameters to fill the
> blocks used.
> The idea would be to use a Requestor object, using the #requestor:
> message,
> which wil act as an interface between the service user and the
> service :
>
> For each of the arguments needed by the service (for the refactoring
> service, these would
> be : selectionNode, and then class, selector, selection), a method is
> triggered in the
> Requestor : requestSelectionNode, requestClass, requestSelector,
> requestSelection.
What you're saying is that when the service sees a block like
[:class | self doSomethingWith: class]
it will send #requestClass, before invoking that block, based on the
name of the argument. I really don't like this - argument names should
not affect behavior. I do realize that you're trying to make the
interface as concise as possible, but I don't think the tradeoff is
worth it in this case. I would much rather, for example, just get
passed the requestor directly:
[:req | self doSomethingWith: req requestClass]
It's a handful more characters, but much easier to trace through, and
doesn't suddenly break if the source code disappears for some reason...
I also find the use of strings as the main way to refer to services odd
- I'd rather deal directly with the Service objects, and have them
returned from some easily accessible method. For example, I'd prefer
TheWorldMenu openService execute
to
'open menu' executeService.
Cheers,
Avi
More information about the Squeak-dev
mailing list
|