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@gmail.com wrote:
On 27 April 2010 05:08, Andreas Raab andreas.raab@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.