what is <localMetaclassMethod>
Locked
what is <localMetaclassMethod>
 
|
Hi
what is this pragma in metaclass method? Stef |
|
|
I don't know, but how you you find documentation about specific pragmas?
Hernán 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: > Hi > > what is this pragma in metaclass method? > > Stef > |
Re: what is <localMetaclassMethod>
|
|
This is one of the problem we will have to fix one of these days.
Pragmas are missing PragmasType as we talk about it in the past. On Sun, Feb 11, 2018 at 7:47 PM, Hernán Morales Durand <[hidden email]> wrote: > I don't know, but how you you find documentation about specific pragmas? > > Hernán > > > 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: >> Hi >> >> what is this pragma in metaclass method? >> >> Stef >> > |
Re: what is <localMetaclassMethod>
|
|
In reply to this post by hernanmd
Hi Hernan,
_,,,^..^,,,_ (phone) > On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand <[hidden email]> wrote: > > I don't know, but how you you find documentation about specific pragmas? The best way is to ensure the pragma has at least one implementation, i.e. there is at least one method in the system that has the same signature as the pragma. This implementation should document the pragma, but even better it should be the method that extracts information from the pragma. An example will help. Imagine a pragma that specifies a method belongs on some menu. The method containing the pragma is intended to be an action of the menu, do that when the menu item is selected, the method containing the pragma will b executed. The pragma defines the menu the method belongs to, where in the method, the string to appear in the menu, the hot key for the menu item, etc. If the pragma is implemented by a menu builder then - yes, certainly the pragma can be documented in the m by builder's implementation, but also - the menu can be built by performing the pragma by the menu builder This was my intent when Steve Dahl and I invented pragmas, that there would always be implementations of the pragma in classes that were designed to extract the information from the pragma and add the method containing the pragma to whatever structure the pragma was intended to facilitate updating (menus, inspectors, exported apis, etc). So the most powerful way of use my pragmas is via a visitor pattern: When a method with a particular pragma is added or removed, the class containing the method triggers some action. This action collects all the relevant pragma methods in the class hierarchy, creates some builder object, and has the builder perform each method containing a relevant pragma. Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that pragmas are messages, and that hence one can do senders and implementors /and/ perform them. HTH > > Hernán > > > 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: >> Hi >> >> what is this pragma in metaclass method? >> >> Stef >> > |
|
|
Hi Eliot,
One could say that a pragma is a message without a method? I think pragmas were never been integrated properly into the system browser. We can browses pragmas with the PragmaCollection but what I mean is a pragma-aware browser. See for example, there are some pragmas where is easy to infer the meaning: <magritteDescription>, <gtInspectorPresentationOrder:>, and others <eProperty> where is not so clear. So even if we take <gtInspectorPresentationOrder:> is not easy with the current tools to find of which parameters makes sense. I always missed something like the annotation pane plugin or the quality assistant plugin in Nautilus, but for pragmas. This could be an excellent opportunity for Calypso to see how pragmas can be exploited in the way you describe. Thanks for the kind explanation. Cheers, Hernán 2018-02-12 1:09 GMT-03:00 Eliot Miranda <[hidden email]>: > Hi Hernan, > > > > > _,,,^..^,,,_ (phone) >> On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand <[hidden email]> wrote: >> >> I don't know, but how you you find documentation about specific pragmas? > > The best way is to ensure the pragma has at least one implementation, i.e. there is at least one method in the system that has the same signature as the pragma. This implementation should document the pragma, but even better it should be the method that extracts information from the pragma. > > An example will help. Imagine a pragma that specifies a method belongs on some menu. The method containing the pragma is intended to be an action of the menu, do that when the menu item is selected, the method containing the pragma will b executed. The pragma defines the menu the method belongs to, where in the method, the string to appear in the menu, the hot key for the menu item, etc. > > If the pragma is implemented by a menu builder then > - yes, certainly the pragma can be documented in the m by builder's implementation, but also > - the menu can be built by performing the pragma by the menu builder > > This was my intent when Steve Dahl and I invented pragmas, that there would always be implementations of the pragma in classes that were designed to extract the information from the pragma and add the method containing the pragma to whatever structure the pragma was intended to facilitate updating (menus, inspectors, exported apis, etc). So the most powerful way of use my pragmas is via a visitor pattern: > > When a method with a particular pragma is added or removed, the class containing the method triggers some action. This action collects all the relevant pragma methods in the class hierarchy, creates some builder object, and has the builder perform each method containing a relevant pragma. > > Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that pragmas are messages, and that hence one can do senders and implementors /and/ perform them. > > HTH > >> >> Hernán >> >> >> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: >>> Hi >>> >>> what is this pragma in metaclass method? >>> >>> Stef >>> >> > |
Re: what is <localMetaclassMethod>
|
|
Hi Hernan,
2018-02-12 7:48 GMT+01:00 Hernán Morales Durand <[hidden email]>: > Hi Eliot, > > One could say that a pragma is a message without a method? > > I think pragmas were never been integrated properly into the system > browser. We can browses pragmas with the PragmaCollection but what I > mean is a pragma-aware browser. See for example, there are some > pragmas where is easy to infer the meaning: <magritteDescription>, > <gtInspectorPresentationOrder:>, and others <eProperty> where is not > so clear. So even if we take <gtInspectorPresentationOrder:> is not > easy with the current tools to find of which parameters makes sense. I > always missed something like the annotation pane plugin or the quality > assistant plugin in Nautilus, but for pragmas. What Eliot is pointing out, is that integration is very easy to do as long as you implement it the way Eliot describes it: you see a pragma, you select it, search for implementors, and, voilà, you know what the pragma is for and how it is used (and you may even get a comment for the parameters). Now, you can try to do that in Pharo, and, of course that doesn't work: I can select the pragma <gtInspectorPresentationOrder: 40>, search for implementors, and I get none. If I search for senders, among the few hundreds of senders I get into my pharo 6 image, and knowing that this should be inside the GT-Inspector-Core package, I find: #GTInspector class >>#extensionsPragma Now, following senders of #extensionsPragma, I find about a dozen senders (because there are multiple implementors of #extensionsPragma, probably). One of the senders is probably the key: ProtoObject>>#gtInspectorPresentationsIn:inContext: And the use of #allNamed:from:to:sortedUsing: should give you a clue about the argument (because, yes there is no comment about the argument... or even if the pragma should have one...). > This could be an excellent opportunity for Calypso to see how pragmas > can be exploited in the way you describe. As I said above, if used like Eliot describes, then it could be done just by searching implementors of the pragma symbol. Now, implemented as it is in Pharo, I suspect it will be hard to do even for Calypso. Regards, Thierry > Thanks for the kind explanation. > > Cheers, > > Hernán > > > 2018-02-12 1:09 GMT-03:00 Eliot Miranda <[hidden email]>: >> Hi Hernan, >> >> >> >> >> _,,,^..^,,,_ (phone) >>> On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand <[hidden email]> wrote: >>> >>> I don't know, but how you you find documentation about specific pragmas? >> >> The best way is to ensure the pragma has at least one implementation, i.e. there is at least one method in the system that has the same signature as the pragma. This implementation should document the pragma, but even better it should be the method that extracts information from the pragma. >> >> An example will help. Imagine a pragma that specifies a method belongs on some menu. The method containing the pragma is intended to be an action of the menu, do that when the menu item is selected, the method containing the pragma will b executed. The pragma defines the menu the method belongs to, where in the method, the string to appear in the menu, the hot key for the menu item, etc. >> >> If the pragma is implemented by a menu builder then >> - yes, certainly the pragma can be documented in the m by builder's implementation, but also >> - the menu can be built by performing the pragma by the menu builder >> >> This was my intent when Steve Dahl and I invented pragmas, that there would always be implementations of the pragma in classes that were designed to extract the information from the pragma and add the method containing the pragma to whatever structure the pragma was intended to facilitate updating (menus, inspectors, exported apis, etc). So the most powerful way of use my pragmas is via a visitor pattern: >> >> When a method with a particular pragma is added or removed, the class containing the method triggers some action. This action collects all the relevant pragma methods in the class hierarchy, creates some builder object, and has the builder perform each method containing a relevant pragma. >> >> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that pragmas are messages, and that hence one can do senders and implementors /and/ perform them. >> >> HTH >> >>> >>> Hernán >>> >>> >>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: >>>> Hi >>>> >>>> what is this pragma in metaclass method? >>>> >>>> Stef >>>> >>> >> > |
Re: what is <localMetaclassMethod>
|
|
It sounds like thinking data vs thinking behavior. Eliot teaches that pragmas should better be used as behavior.2018-02-12 9:48 GMT+01:00 Thierry Goubier <[hidden email]>: Hi Hernan, |
|
|
In reply to this post by Thierry Goubier
Hi Thierry,
2018-02-12 5:48 GMT-03:00 Thierry Goubier <[hidden email]>: > Hi Hernan, > > 2018-02-12 7:48 GMT+01:00 Hernán Morales Durand <[hidden email]>: >> Hi Eliot, >> >> One could say that a pragma is a message without a method? >> >> I think pragmas were never been integrated properly into the system >> browser. We can browses pragmas with the PragmaCollection but what I >> mean is a pragma-aware browser. See for example, there are some >> pragmas where is easy to infer the meaning: <magritteDescription>, >> <gtInspectorPresentationOrder:>, and others <eProperty> where is not >> so clear. So even if we take <gtInspectorPresentationOrder:> is not >> easy with the current tools to find of which parameters makes sense. I >> always missed something like the annotation pane plugin or the quality >> assistant plugin in Nautilus, but for pragmas. > > What Eliot is pointing out, is that integration is very easy to do as > long as you implement it the way Eliot describes it: you see a pragma, > you select it, search for implementors, and, voilà, you know what the > pragma is for and how it is used (and you may even get a comment for > the parameters). > > Now, you can try to do that in Pharo, and, of course that doesn't > work: I can select the pragma <gtInspectorPresentationOrder: 40>, > search for implementors, and I get none. If I search for senders, > among the few hundreds of senders I get into my pharo 6 image, and > knowing that this should be inside the GT-Inspector-Core package, I > find: > > #GTInspector class >>#extensionsPragma > > Now, following senders of #extensionsPragma, I find about a dozen > senders (because there are multiple implementors of #extensionsPragma, > probably). One of the senders is probably the key: > > ProtoObject>>#gtInspectorPresentationsIn:inContext: > > And the use of #allNamed:from:to:sortedUsing: should give you a clue > about the argument (because, yes there is no comment about the > argument... or even if the pragma should have one...). > As you noted, that's a long way to find a pragma information. It should be a lot easier. >> This could be an excellent opportunity for Calypso to see how pragmas >> can be exploited in the way you describe. > > As I said above, if used like Eliot describes, then it could be done > just by searching implementors of the pragma symbol. > > Now, implemented as it is in Pharo, I suspect it will be hard to do > even for Calypso. > I see. I would love a popup after each new pragma is defined to write some description. The system can enforce to write documentation! ;) Best regards, Hernán > Regards, > > Thierry > >> Thanks for the kind explanation. >> >> Cheers, >> >> Hernán >> >> >> 2018-02-12 1:09 GMT-03:00 Eliot Miranda <[hidden email]>: >>> Hi Hernan, >>> >>> >>> >>> >>> _,,,^..^,,,_ (phone) >>>> On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand <[hidden email]> wrote: >>>> >>>> I don't know, but how you you find documentation about specific pragmas? >>> >>> The best way is to ensure the pragma has at least one implementation, i.e. there is at least one method in the system that has the same signature as the pragma. This implementation should document the pragma, but even better it should be the method that extracts information from the pragma. >>> >>> An example will help. Imagine a pragma that specifies a method belongs on some menu. The method containing the pragma is intended to be an action of the menu, do that when the menu item is selected, the method containing the pragma will b executed. The pragma defines the menu the method belongs to, where in the method, the string to appear in the menu, the hot key for the menu item, etc. >>> >>> If the pragma is implemented by a menu builder then >>> - yes, certainly the pragma can be documented in the m by builder's implementation, but also >>> - the menu can be built by performing the pragma by the menu builder >>> >>> This was my intent when Steve Dahl and I invented pragmas, that there would always be implementations of the pragma in classes that were designed to extract the information from the pragma and add the method containing the pragma to whatever structure the pragma was intended to facilitate updating (menus, inspectors, exported apis, etc). So the most powerful way of use my pragmas is via a visitor pattern: >>> >>> When a method with a particular pragma is added or removed, the class containing the method triggers some action. This action collects all the relevant pragma methods in the class hierarchy, creates some builder object, and has the builder perform each method containing a relevant pragma. >>> >>> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that pragmas are messages, and that hence one can do senders and implementors /and/ perform them. >>> >>> HTH >>> >>>> >>>> Hernán >>>> >>>> >>>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <[hidden email]>: >>>>> Hi >>>>> >>>>> what is this pragma in metaclass method? >>>>> >>>>> Stef >>>>> >>>> >>> >> > |
Re: what is <localMetaclassMethod>
|
|
In reply to this post by Stephane Ducasse-3
So I got the answer: pragmas to be removed. So I will remove them.
Stef On Sun, Feb 11, 2018 at 6:48 PM, Stephane Ducasse <[hidden email]> wrote: > Hi > > what is this pragma in metaclass method? > > Stef |
Re: what is <localMetaclassMethod>
|
|
Thierry when I select a pragma and do senders of I see all the users.
Now I do not see why this would be difficult to see to have implementors. And pragma can be use to perform action now people can decide to do what they want. Since pragma arguments are literal, I think that for example the choice of pargram as a marker as in settings is much better. So it depends on the scenario. Now the point is not here. The point is that we should reify the pragma family/type to attach to it query, verification and documentation. Stef On Tue, Feb 13, 2018 at 9:05 AM, Stephane Ducasse <[hidden email]> wrote: > So I got the answer: pragmas to be removed. So I will remove them. > > Stef > > On Sun, Feb 11, 2018 at 6:48 PM, Stephane Ducasse > <[hidden email]> wrote: >> Hi >> >> what is this pragma in metaclass method? >> >> Stef |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |