Note that we could also handle the two types of pragmas (with a
crossfork compatibility layer).
However, only one should existin core image IMO (simplicity, homogeneity).

We could also auto-generate Pharo-pragmas from Squeak-pragmas, but the
reverse would be very hard.

Nicolas


2010/4/27 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 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.
>>>>
>>>>
>>>
>>>
>>
>>
>