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