2010/4/27 Hannes Hirzel <hannes.hirzel at gmail.com>:
> What are the reasons for not going for the Pharo solution?
>
> --Hannes
>

Andreas just put it nicely.
There is a different philosophy, and that is important to discuss
first, and weight pros and cons.
The difference is that package maintainers should care of system
evolutions in Pharo, but won't care of building details anymore in
Squeak.
Of course, this is at the price of restricting functionalities.

Nicolas

> On 4/27/10, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2010/4/27 Sean P. DeNigris <sean at clipperadams.com>:
>>>
>>> I will post replies I get in pharo-project here as a resource in this
>>> conversation:
>>>
>>> Pharo menus can have pre-condition blocks:
>>> Hi Sean,
>>> you can declare a menu item with a precondition block.
>>> the menu item is not added to the menu if the precondition is false.
>>> We have one example in the core. See the precondition in the #'Software
>>> update' item.
>>>
>>> WorldState class>>systemOn: aBuilder
>>>    <worldMenu>
>>>    (aBuilder item: #System)
>>>        order: 4.0;
>>>        withSeparatorAfter;
>>>        icon: MenuIcons smallConfigurationIcon;
>>>        with: [
>>>            (aBuilder item: #'About...')
>>>                order: 0;
>>>                action: [Smalltalk aboutThisSystem].
>>>            (aBuilder item: #'Software update')
>>>                order: 1;
>>>                precondition: [self showUpdateOptionInWorldMenu];
>>>                action: [Utilities updateFromServer];
>>>                help: 'Load latest code updates via the internet']
>>>
>>> A take on the pros and cons of existing preference style v.s. Pharo menu
>>> style:
>>> Comparing Settings to Preference Annotations might gleam at the difference
>>> you might expect between menu annotations in Pharo and Squeak.
>>>
>>> In Pharo the method contains a simple annotation with no args, and the
>>> method contains code for building a menuitem using the builder passed as
>>> argument,
>>> My speculation: If following the existing preference-style, Squeak will
>>> probably use an annotation with more args, with the method body containing
>>> the actual action.
>>> i.e. Alains example would be written something like:
>>> WorldState class>>aboutMenuItem
>>> <menuItemIn: #('WorldMenu' 'System')
>>>        order: 0
>>>        label: 'About... '>
>>> Smalltalk aboutThisSystem
>>>
>>> WorldState>>updateFromServertMenuItem
>>> <menuItemIn: #('WorldMenu' 'System')
>>>        order: 1
>>>        label: 'About... '
>>>        visible: #showUpdateOptionInWorldMenu
>>>        help: 'Load latest code updates via the internet'>
>>> Utilites updateFromServer
>>>
>>>
>>> Both approaches have their pros and cons.
>>> The one in Pharo depends on a builder responding to certain messages, so
>>> expanding the API might lead to breakage if you try to load into an old
>>> image.
>>> You also have to define new annotation keywords for each menu you want to
>>> build this way, .
>>>
>>> The one for Squeak might suffer a risk of needing a large amount of
>>> permutations of annotations  , depending on which PluggableMenuItemSpec
>>> properties you'd want to be able to leave optional.
>>>
>>
>> Would it be possible to use known techniques like cascading?
>> <menuItemIn: #('WorldMenu' 'System');
>>         order: 1;
>>         label: 'About... ';
>>         visible: #showUpdateOptionInWorldMenu;
>>         help: 'Load latest code updates via the internet'>
>> The idea would be to send messages to a Builder.
>> The builder would have a current target (created by #menuItemIn:) to
>> which subsequent messages would be sent...
>> Not sure at all cascading is allowed now, but it eventually could.
>>
>>> In short: In Pharo you have access to the builder in the method, while in
>>> Squeak (based on how Preferences annotations work) I'd expect they end up
>>> with a builder parsing an annotation instead.
>>>
>>
>> My first impression is that while Pharo is reacher, it is also weaker
>> w.r.t. core system evolutions because exposing more API.
>> The difference is subtle though, because my above cascade example is
>> also exposing an API...
>> But it is different : we don't have to just execute the cascade, we
>> could catch and ignore every not-understood message, and proceed with
>> the next one...
>> ... or we could also preprocess and transform the messages etc...
>>
>> One advantage of Pharo is the possibility to insert a halt in the
>> constructing phase, but hey, we could place a halt: in the cascade
>> too...
>> Pharo solution also gives reflection on the builder, which is
>> powerfull, the pragma/annotation does not.
>>
>> If we can't agree though, the nice thing with pragmas/annotations is
>> that both menu declaration can co-exist (as long as keyword don't
>> conflict).
>> Package developpers would have to provide two hooks, and code critics
>> might complain of some missing API, but that's not a drama.
>>
>> Nicolas
>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>