The Inbox: Morphic-phite.429.mcz

> On 4/26/2010 3:47 PM, Hannes Hirzel wrote:
>> And: to me the code for the menu definitions looks ugly. A kind of
>> assembler like, lisp-s expression thing with a lot of implied
>> assumptions.
>
> I think you're missing the point of why one would use an annotation.
> They're there for discovery by other code. You are basically announcing
> "hey if anyone cares, here's an action that you might want to place in a
> menu".
>
> MenuSpec doesn't achieve that. Yes, you got a menu spec, but now what?
> You also need a registry, let's say TheWorldMenu. Then you add another
> registry for TheMainDockingBar. Then we refactor this and introduce new
> classes, say the TheMainMenu and TheContextMenu. Now you've got to deal
> with four different situations. This all goes away by using annotations.
> If there's code that knows how to discover these specs, it will do so.
> If not, it just leaves the code alone.
>
> Most importantly a third party trying to extend the main menu doesn't
> need to update their code because the implementation in the base system
> changes.
>
>> The MenuSpec is a straighforward thing. And I think it is more
>> appealing for the younger generation.
>
> I fail to see what age has to do with this discussion. However, if you
> look at the "current" crowd of programming languages they pretty much
> all have annotations, from C# to Python, which are used for very similar
> purposes.
>
>> The practical problem we are currently facing with Squeak 4.1 is that
>> it cannot display pictures in the the file browser and that adding
>> entries to the menu is not possible in a clean way.
>
> Correct, but I see this as a an example of a discussion on how we
> achieve a more decoupled system. For the purpose at hand, where we'd
> like 3rd parties to use and extend the base system while allowing the
> base system itself to evolve, I find the annotation-based discovery
> superior to hardcoded references to classes and registries that may not
> exist in this form in the future.
>
> Cheers,
>    - Andreas
>
>

> On 27.04.2010, at 00:47, Hannes Hirzel wrote:
>>
>> And: to me the code for the menu definitions looks ugly. A kind of
>> assembler like, lisp-s expression thing with a lot of implied
>> assumptions.
>
> You mean this?
>
> MenuEntrySpec newFrom: (Dictionary newFromPairs: #(
> contents 'Well... hello?'
> help 'Displays the Hello World'
> location ('Help')
> target MenuMorph selector inform: arguments ('Hello World!')
> position first))

> On 4/26/10, Bert Freudenberg <[hidden email]> wrote:
>> On 27.04.2010, at 00:47, Hannes Hirzel wrote:
>>>
>>> And: to me the code for the menu definitions looks ugly. A kind of
>>> assembler like, lisp-s expression thing with a lot of implied
>>> assumptions.
>>
>> You mean this?
>>
>> MenuEntrySpec newFrom: (Dictionary newFromPairs: #(
>> contents 'Well... hello?'
>> help 'Displays the Hello World'
>> location ('Help')
>> target MenuMorph selector inform: arguments ('Hello World!')
>> position first))
>

> On 27 April 2010 02:11, Andreas Raab <[hidden email]> wrote:
>> I find the annotation-based discovery superior to hardcoded
>> references to classes and registries that may not exist in this  
>> form in the
>> future.
>>
> +1
>> Cheers,
>>  - Andreas
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> On Apr 26, 2010, at 6:45 PM, Igor Stasenko <[hidden email]> wrote:
>
>> On 27 April 2010 02:11, Andreas Raab <[hidden email]> wrote:
>>> I find the annotation-based discovery superior to hardcoded
>>> references to classes and registries that may not exist in this form
>>> in the
>>> future.
>>>
>> +1
>>> Cheers,
>>> - Andreas
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>

>> Cheers,
>>  - Andreas
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

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

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

> On 27 April 2010 05:08, Andreas Raab <[hidden email]> 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.
>

> On 27 April 2010 05:08, Andreas Raab<[hidden email]>  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}}

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

> On 4/26/2010 8:04 PM, Igor Stasenko wrote:
>>
>> On 27 April 2010 05:08, Andreas Raab<[hidden email]>  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.
>

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

>
> --Hannes
>
> On 4/26/10, Bert Freudenberg <[hidden email]> wrote:
>> On 27.04.2010, at 00:21, Hannes Hirzel wrote:
>>>
>>>> Terminology is important and the terminology we currently
>>>> have is *extremely* confusing.
>>>
>>> And that is why I am reluctant having these pragmas 'crawl' into menu
>>> definitions.
>>
>> Now that's just silly, sorry. Nobody is questioning the utility of these
>> guys, whatever we call them.
>>
>> - Bert -
>>
>>
>>
>>
>
>

>> Yes, I do not question the usefulness of pragmas for what they have
>> been used so far. Primitives and version control related things. I
>> oppose to use them in addition for menu definitions.
>
> Hi Hannes, I agree with you.  A new non-Smalltalk construct appears
> and we see that it starts to get used for lots of things where before
> we would have just used plain Smalltalk..
>
> Can we stay with Smalltalk everywhere except where it's impossible or
> impractical to?
>
>> adding
>> entries to the menu is not possible in a clean way.
>
> I don't know about displaying the pictures, I just use the 'open'
> button.  But, I do use the "services" function to add my own custom
> application functions to the file-list.  Did you know about that or
> are you saying that it needs improvement..?
>
>>
>> --Hannes
>>
>> On 4/26/10, Bert Freudenberg <[hidden email]> wrote:
>>> On 27.04.2010, at 00:21, Hannes Hirzel wrote:
>>>>
>>>>> Terminology is important and the terminology we currently
>>>>> have is *extremely* confusing.
>>>>
>>>> And that is why I am reluctant having these pragmas 'crawl' into menu
>>>> definitions.
>>>
>>> Now that's just silly, sorry. Nobody is questioning the utility of these
>>> guys, whatever we call them.
>>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>
>>
>

> Nevermind..  I'm late to this party..
>
> On Wed, Apr 28, 2010 at 2:18 PM, Chris Muller <[hidden email]> wrote:
>>> Yes, I do not question the usefulness of pragmas for what they have
>>> been used so far. Primitives and version control related things. I
>>> oppose to use them in addition for menu definitions.
>>
>> Hi Hannes, I agree with you.  A new non-Smalltalk construct appears
>> and we see that it starts to get used for lots of things where before
>> we would have just used plain Smalltalk..
>>
>> Can we stay with Smalltalk everywhere except where it's impossible or
>> impractical to?
>>
>>> adding
>>> entries to the menu is not possible in a clean way.
>>
>> I don't know about displaying the pictures, I just use the 'open'
>> button.  But, I do use the "services" function to add my own custom
>> application functions to the file-list.  Did you know about that or
>> are you saying that it needs improvement..?
>>
>>>
>>> --Hannes
>>>
>>> On 4/26/10, Bert Freudenberg <[hidden email]> wrote:
>>>> On 27.04.2010, at 00:21, Hannes Hirzel wrote:
>>>>>
>>>>>> Terminology is important and the terminology we currently
>>>>>> have is *extremely* confusing.
>>>>>
>>>>> And that is why I am reluctant having these pragmas 'crawl' into menu
>>>>> definitions.
>>>>
>>>> Now that's just silly, sorry. Nobody is questioning the utility of these
>>>> guys, whatever we call them.
>>>>
>>>> - Bert -
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>