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