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#a... , 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.