[Fwd: Re: [Pharo-project] [squeak-dev] Re: Menu Registries]

Hannes Hirzel a écrit :

Hi Hannes

Unfortunately you've took the wrong version :)

SystemSettings and registrable menu are in 1.1.
Please, take the core and browse again.

I suggest you to first take a look at registrable menu implementation.
only 2 classes : MenuRegistration and PragmaMenuBuilder.
see also the class side of MenuRegistrationExample.

The settings implementation is a little bit more complicated but only
because of the UI.
The setting browser and the setting declaration model are in
System-Settings-* sys cat. (removable)
The Setting-* sys categories contain all settings declaration (they are
removable and do not depend on ANY other setting related package thanks
to the builder pattern).
They are declared in order to allow their browsing through the use of
the SettingBrowser.
Preferences are simply class variables which are declared locally where
they are used (as in Squeak but without pragma)

Pragma discovering for menu and settings makes use of PragmaCollector
(see the class comment).

I can explain more but please browse the code before.
> QUESTIONS
> A. The fact that you refer me to Google and the Nabble list to find
> out the result of your pragma discussion has to be read as - there is
> no such document yet. Is this correct?
>  
a documentation about the setting framework in under construction.
> B. Is there a list of pragmas and how they are supposed to be used?
>  
<systemsettings> and <worldMenu>
browse all senders to #systemsettings and to #worldMenu to find all
settings and menu items declarations.
> C. How do you want to handle the menus with pragmas? (It seems that
> Pharo is not much further advanced in this area).
>  
again, in 1.1, the world menu is fully dynamically built using pragma
(the same implementation scheme as for settings is used).


Cheers
Alain
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>  

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.