2015-02-06 18:29 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>: > > > On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <thierry.goub...@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
