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