Thank you Alain for your detailed answer.

I will have a look at the dynamic menu code in Pharo 1.1

Lukas Renggli and Markus Denker gave helpful answers as well on the
Pharo list only.
I copy them in below.
--Hannes


----------------------------------------------------------------------------------------------------------------------------

Two messages regarding pragmas and menu construction from the Pharo list


Lukas Renggli answered


Pragmas were forcibly added in Squeak 3.9 to catch up with the modern world.


Check out Pharo 1.1, this is where the setting and the menus are built
using pragmas.

> Is there a list of pragmas and how they are supposed to be used?

Pragmas are not declared statically as this is the case in
VisualWorks. A class that uses certain pragmas should document it of
course, but similar to the way you can send any message and define any
message you can define any pragma and search for any pragma. It's
dynamic as with message sends.

Lukas





Henrik Sperre Johansen

In:
http://forum.world.st/Fix-2329-Default-MC-Directory-Setting-td2019559.html#a2020047
,
 I wrote exactly where to find the code dealing with pragma discovery
in both Pharo 1.1 and Squeak 4.1.

    C. How do you want to handle the menus with pragmas? (It seems that
    Pharo is not much further advanced in this area).

They are handled exactly the same way Preferences is handled.
A PragmaCollector is told to find pragmas with a specific keyword.
(#systemsettings or #worldmenu respectively for Settings and the World
menu (currently the only dynamic menu in Pharo 1.1).
For the methods discovered, you then:
- for preferences: Pass in a preference builder to the method, which
can then construct its preferences.
- for menus: Pass in a menu builder to the method, which can then
construct the menu items it needs.


To the argument "But a builder decoupled from the method provides
resistance to further change!" I say:
How is that different from any of the many methods currently expecting
as argument an instance of a class in base?
If the base classes does indeed change, what would you rather see happening?
a) An MNU or deprecated warning when trying to invoke the (now) invalid code?
b) The code simply not doing what you expect it to? (ie. not adding
menu items etc.)

Yes, in b) you can still import old code and run it with no errors.
That does not necessarily mean it does what you wanted it to do
though.

Cheers,
Henry

PS. I actually like the Squeak preference pragma. In 99% of the cases,
it is sufficient, and you can place it directly as metadata in an
existing accessor method, rather than having to define a new method
simply for defining a method whose only difference from 30 others is
what variable it stores into and reads from.