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}}]
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.
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.
Cheers, - Andreas