Good summary, but some things are better explained in a more persistent 
format, so I've written up the motivation here:

http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/

(does anyone know how to fix up the font for <pre> at wordpress?)

Cheers,
   - Andreas

On 4/27/2010 9:45 AM, Sean P. DeNigris wrote:
>
> 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.
>
> 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.
>