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

Igor Stasenko siguctua at gmail.com
Tue Apr 27 04:36:41 UTC 2010

On 27 April 2010 06:33, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.
Well, from other side, if it breaks, then you know that something goes
wrong and needs to be fixed.
Its really depends on intent. Nothing stopping you from implementing a
DNU handler
which ignoring uknown messages and warns user istead of opening debugger.

> 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.
I am not opposed to annotations. I'm just pointing out that they
having own limits.

>> 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.
Not necessarily in Object.
I'm already proposed before to use Smalltalk as a hub for all such things..
For example:

Smalltalk userInterface browser open.

Smalltalk userInterface mainMenu registerMenuItem: ....

Smalltalk vm version.

and so on.

> 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

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list