2015-02-06 18:29 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:


On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Eliot,

maybe I'll frame the core question a bit differently, thanks to your explanations.

I see pragmas used mainly for two things:

1- expressing a link to some metadata used by low level tools: compiler, C lang generator, etc... primitives for me are part of that. Kind of neat to see that unified.

There's a third use that is, I think, the most powerful.� Maybe you see this as the same as 1, but I don't.� The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector.� The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it.� This is how menu pragmas work in VW.� There is an object called a MenuBuilder.� To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma.� The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu.� But the execution of the pragma is what actually adds the mehtod to the menu.� So its a combination of specification and execution.

You mean as a sort of lightweight command object? Pharo uses that for its world menu, Nautilus for its menus, and probably in a few other places. I also like to define command objects for that purpose, because it gives you more flexibility and power while keeping all concerns together: complex commands depending on the context of their creator, having both a menu entry and a shortcut, controlling whether they are enabled or not... I also like command objects because they usually force a bit of a dedicated category for them, and may avoid a spread of pragmas tagged methods left and right in the package.


I have no problem with your criticism of pragmas used for categorisation.� Method categories are already there and sometimes much more appropriate than pragmas.� For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses.� If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want.� Instead I copy across the methods in the relevant categories.

But this "not a complete solution" feels to me an unfair criticism.� Pragmas are what they are and they can do a lot.� But no part of the system does everything.� A system is composed of components.

I agree with that, and the fact that well, maybe, someone will come along with something better :)

Thierry