In addition. What prevents us from defining a protocol to rule out
other (unstable) protocols? :)

(self systemProtocol: 'Squeak4.1' )  ifNotNilDo: [:protocol |
  protocol globalMenuRegistry addStuff.... ]

On 27 April 2010 06:04, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.