What are the reasons for not going for the Pharo solution?

--Hannes

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