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

Andreas Raab andreas.raab at gmx.de
Tue Apr 27 03:33:07 UTC 2010


On 4/26/2010 8:04 PM, Igor Stasenko wrote:
> On 27 April 2010 05:08, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> 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}}

That assumes that #worldMenu is on class Object. An assurance that you 
can't make over time. So whoever is trying to extend the system is 
forced to adapt the code for any and all supported versions since you 
don't have a way of safely ignoring things.

>> 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>
> ?

I don't know. But it doesn't break. Even in its most naive use. The 
service isn't recognized by the system you install it in, but it doesn't 
blow up in your face. Given that we're trying to move things forward and 
build them in a modular way, I think that's a good property.

BTW, only when you put *all* of it together, avoiding the need to refer 
to external global class names, avoiding the need to explicitly test for 
method compliance, automatic discovery by many tools (i.e., both the 
world menu and the docking bar can discover the same menu annotation but 
you'd have to provide separate selectors or globals to adjust for that), 
being both forward and backwards compatible; so when you put *all* of 
this together, there is no doubt in my mind that annotations are 
superior to the proposed alternatives. They have weaknesses, admitted, 
but these weaknesses are negligible for an application like we're 
discussing here.

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

That's definitely an important aspect and holds for annotations as well.

> 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.

Are you actually proposing to introduce Object>>worldMenu? If so, I'm 
completely opposed to the proposal. Polluting the global namespace like 
that serves no purpose whatsoever.

OTOH, if you're saying that we should evaluate the use of annotations 
carefully in the context of each potential use, I'm with you. I don't 
like an abuse of annotations either. However, for situations like we're 
talking about, where third party code tries to add services to the base 
system, I think it's a good idea. That includes its use for preferences, 
the world menu / docking bar, and for example file services.

>> 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.

True. It's harder to debug annotations if they don't do what you think 
they should. A good reason for keeping 'em simple.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list