[squeak-dev] Re: Pragmas (Re: The Inbox: Morphic-phite.429.mcz)

Igor Stasenko siguctua at gmail.com
Tue Apr 27 03:04:57 UTC 2010

On 27 April 2010 05:08, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 4/26/2010 5:13 PM, Igor Stasenko wrote:
>> So, we could have our cake and eating it too:
>> - do not use globals (like MenuEntrySpec). Really, a format (or class)
>> which is used for holding a menu spec is totally irrelevant to an
>> external package. So, why external package should care about these
>> details, why not like following:
>> Object>>globalMenuRegistry
>>   ^ World menuRegistry "whatever"
>> MyExternalPackageClass class>>initialize
>>   self addMenuEntry.
>> MyExternalPackageClass class>>addMenuEntry
>>    self globalMenuRegistry addMenuEntry: #(
>>        contents 'Well... hello?'
>>                 help 'Displays the Hello World'
>>                 location ('Help')
>>                 target selector #inform: arguments ('Hello World!')
>>                 position first)
>>       forClass: self
>> So, as simple as that:
>>  - an external package expects from system to support a certain
>> protocol, which can be used to access various system services
>> (in our case , this is a #globalMenuRegistry)
>> - an external package expects from menuRegistry to support a certain
>> protocol, which can be used to add menu entries and control other
>> various properties.
>> So, that's how we can at the same time keep system decoupled, and be
>> able to have a direct communications between service&  consumer.
>> Just stop using globals and build the basic system infrastructure
>> based on message sends and protocols.
> That ends up with code like here:
> MCWorkingCopy class>>initialize
>         (TheWorldMenu respondsTo: #registerOpenCommand:)
>         ifTrue: [TheWorldMenu registerOpenCommand: {'Monticello Browser'.
> {self. #open}}]
nope it doesn't.
It should look like:

 MCWorkingCopy class>>initialize
     self worldMenu registerOpenCommand: {'Monticello Browser'.  {self. #open}}

> which is precisely why I don't like it. It is also subject to the evolution
> system - how long is it going to take until we figure that the method
> shouldn't be called Object>>globalMenuRegistry etc.
But same applies to annotations.

How long it will take to figure out that instead of

<createDockingBarMenuWithPriority: 50>

you need:

<createDockingBarMenuWithPriority: 50 andColor: #red>

Take it or leave it, but all such #createDockingBarMenuWithPriority:
is also defines a  protocol,
which something somewhere must recognize and react on it in order to
make things work. Isnt?

And so, i think designing a good, future-proof protocols is answer to
your question.

I'm not saying that we should hastily add tons of
Object>>serviceXXxXxxxRegistry etc..

lets wisely consider what we need and slowly introduce it by
deprecating the old uses.

> Finally, I should also add that you *can* browse senders and implementors of
> annotations. Try for example browsing senders/implementors of
> #preference:category:description:type: to see what I mean.
Yes, you can.
But still its a little different from putting a halt and see how it
works and where it goes.

> Cheers,
>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list