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

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