New pragmas 'alias' and 'aliasedBy'?
Locked
New pragmas 'alias' and 'aliasedBy'?
 
|
Hi all
I am a student at the University of Bern and for my Master's Thesis I am using the FAMIX metamodel and I also intend to use Fame. One thing that is most valuable for me is the possibility to generate metamodel stub code from an fm3 mse file, in my case Java classes. While filling in the stub classes for FAMIX core, I realized that much of that work could also be done by the generator, if only it had some additional information. So I suggest adding that information as pragmas. Let me explain that on behalf of an example. The message FAMIXNamedEntity>>belongsTo should be overridden in all of FAMIXType FAMIXScopingEntity FAMIXMethod FAMIXFunction FAMIXLocalVariable FAMIXUnknownVariable FAMIXGlobalVariable FAMIXParameter FAMIXAttribute FAMIXImplicitVariable (and more outside FAMIX core) but a code generator does not know that, so I have to implement the corresponding messages/methods by hand. That is a bit annoying since this really is very simple code that could easily be generated. Example for one of the methods that have to be written by hand: FAMIXAttribute>>belongsTo ^ self parentType Every implementation of 'belongsTo' looks like that, i.e. is a very simple delegate, or let us call it an "alias". I suggest to add the information about such "aliases" to the pragmas: 1) add <alias> to NamedEntity>>belongsTo 2) add <aliasedBy #belongsTo> to all subclass properties, e.g. to FAMIXAttribute>>parentType Then, with that kind of information in an mse file, a code generator could do more work for me and I had time to drink an additional coffee or two :) And maybe metamodel browsers can profit from that kind of information, too. Cheers, Raffael Krebs _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: New pragmas 'alias' and 'aliasedBy'?
|
|
Hi Rafael,
Nice to see you again :). The nice feature of FM3 is that it is small. Your change would imply extending FM3 with alias information, and then getting the code generators to understand this part. The problem is that the use case we are talking about is so small, that I am not sure it warrants the trouble of changing FM3. But, could you tell us more about the use case you are in? Is it generating Famix an action that you have to do all the time? Cheers, Doru On 28 Apr 2011, at 12:34, Raffael Krebs wrote: > Hi all > > I am a student at the University of Bern and for my Master's Thesis I am using the FAMIX metamodel and I also intend to use Fame. > > One thing that is most valuable for me is the possibility to generate metamodel stub code from an fm3 mse file, in my case Java classes. > > While filling in the stub classes for FAMIX core, I realized that much of that work could also be done by the generator, if only it had some additional information. So I suggest adding that information as pragmas. > > > > Let me explain that on behalf of an example. > > The message FAMIXNamedEntity>>belongsTo should be overridden in all of > > FAMIXType > FAMIXScopingEntity > FAMIXMethod > FAMIXFunction > FAMIXLocalVariable > FAMIXUnknownVariable > FAMIXGlobalVariable > FAMIXParameter > FAMIXAttribute > FAMIXImplicitVariable > (and more outside FAMIX core) > > but a code generator does not know that, so I have to implement the corresponding messages/methods by hand. That is a bit annoying since this really is very simple code that could easily be generated. > Example for one of the methods that have to be written by hand: > > FAMIXAttribute>>belongsTo > ^ self parentType > > > Every implementation of 'belongsTo' looks like that, i.e. is a very simple delegate, or let us call it an "alias". > > I suggest to add the information about such "aliases" to the pragmas: > > 1) add <alias> to NamedEntity>>belongsTo > 2) add <aliasedBy #belongsTo> to all subclass properties, e.g. to FAMIXAttribute>>parentType > > > > Then, with that kind of information in an mse file, a code generator could do more work for me and I had time to drink an additional coffee or two :) > > And maybe metamodel browsers can profit from that kind of information, too. > > > Cheers, > Raffael Krebs > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: New pragmas 'alias' and 'aliasedBy'?
|
|
Hi Tudor,
I agree that the use case is small but i don't see how adding some pragmas would change FM3. I mean the idea is just to have more static information stored into pragmas that on the one hand can improve the comprehension of the meta-model itself (e.g. knowing which methods are just aliases for something else and so have the same semantic), on the other hand can be use in other contexts like, for instance, the automatically generation of code to make it more efficient. I agree that the code generation is not something that you do all the time but if you want to have something that can go back a forth from a platform to Moose and the other way around it is necessary to make this passage as easy and automatic as possible. Cheers, Fabrizio On 28 Apr 2011, at 13:59, Tudor Girba wrote: > Hi Rafael, > > Nice to see you again :). > > The nice feature of FM3 is that it is small. Your change would imply extending FM3 with alias information, and then getting the code generators to understand this part. > > The problem is that the use case we are talking about is so small, that I am not sure it warrants the trouble of changing FM3. > > But, could you tell us more about the use case you are in? Is it generating Famix an action that you have to do all the time? > > Cheers, > Doru > > > On 28 Apr 2011, at 12:34, Raffael Krebs wrote: > >> Hi all >> >> I am a student at the University of Bern and for my Master's Thesis I am using the FAMIX metamodel and I also intend to use Fame. >> >> One thing that is most valuable for me is the possibility to generate metamodel stub code from an fm3 mse file, in my case Java classes. >> >> While filling in the stub classes for FAMIX core, I realized that much of that work could also be done by the generator, if only it had some additional information. So I suggest adding that information as pragmas. >> >> >> >> Let me explain that on behalf of an example. >> >> The message FAMIXNamedEntity>>belongsTo should be overridden in all of >> >> FAMIXType >> FAMIXScopingEntity >> FAMIXMethod >> FAMIXFunction >> FAMIXLocalVariable >> FAMIXUnknownVariable >> FAMIXGlobalVariable >> FAMIXParameter >> FAMIXAttribute >> FAMIXImplicitVariable >> (and more outside FAMIX core) >> >> but a code generator does not know that, so I have to implement the corresponding messages/methods by hand. That is a bit annoying since this really is very simple code that could easily be generated. >> Example for one of the methods that have to be written by hand: >> >> FAMIXAttribute>>belongsTo >> ^ self parentType >> >> >> Every implementation of 'belongsTo' looks like that, i.e. is a very simple delegate, or let us call it an "alias". >> >> I suggest to add the information about such "aliases" to the pragmas: >> >> 1) add <alias> to NamedEntity>>belongsTo >> 2) add <aliasedBy #belongsTo> to all subclass properties, e.g. to FAMIXAttribute>>parentType >> >> >> >> Then, with that kind of information in an mse file, a code generator could do more work for me and I had time to drink an additional coffee or two :) >> >> And maybe metamodel browsers can profit from that kind of information, too. >> >> >> Cheers, >> Raffael Krebs >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: New pragmas 'alias' and 'aliasedBy'?
|
|
Hi Fabrizio,
On 29 Apr 2011, at 15:00, Fabrizio Perin wrote: > Hi Tudor, > I agree that the use case is small but i don't see how adding some pragmas would change FM3. I mean the idea is just to have more static information stored into pragmas that on the one hand can improve the comprehension of the meta-model itself (e.g. knowing which methods are just aliases for something else and so have the same semantic), on the other hand can be use in other contexts like, for instance, the automatically generation of code to make it more efficient. > > I agree that the code generation is not something that you do all the time but if you want to have something that can go back a forth from a platform to Moose and the other way around it is necessary to make this passage as easy and automatic as possible. This back-and-forth between languages is achieved through FM3. Pragmas are only the means we link the meta-descriptions to the Smalltalk implementation, but in the end, these pragmas must be reflected in FM3 if you want the Java generator to take them into account. If you want to add a new pragma with a new meaning you will have to change FM3 with the new information and then you will have to change the generators to take this new information into account. Now, I did not say that it is not interesting. It is. Of course, everyone is welcome to give such an extension a try :). Will you guys try it? But, basically the only place where this is needed right now is in belongsTo. So, the use case is really small. Cheers, Doru > Cheers, > Fabrizio > > On 28 Apr 2011, at 13:59, Tudor Girba wrote: > >> Hi Rafael, >> >> Nice to see you again :). >> >> The nice feature of FM3 is that it is small. Your change would imply extending FM3 with alias information, and then getting the code generators to understand this part. >> >> The problem is that the use case we are talking about is so small, that I am not sure it warrants the trouble of changing FM3. >> >> But, could you tell us more about the use case you are in? Is it generating Famix an action that you have to do all the time? >> >> Cheers, >> Doru >> >> >> On 28 Apr 2011, at 12:34, Raffael Krebs wrote: >> >>> Hi all >>> >>> I am a student at the University of Bern and for my Master's Thesis I am using the FAMIX metamodel and I also intend to use Fame. >>> >>> One thing that is most valuable for me is the possibility to generate metamodel stub code from an fm3 mse file, in my case Java classes. >>> >>> While filling in the stub classes for FAMIX core, I realized that much of that work could also be done by the generator, if only it had some additional information. So I suggest adding that information as pragmas. >>> >>> >>> >>> Let me explain that on behalf of an example. >>> >>> The message FAMIXNamedEntity>>belongsTo should be overridden in all of >>> >>> FAMIXType >>> FAMIXScopingEntity >>> FAMIXMethod >>> FAMIXFunction >>> FAMIXLocalVariable >>> FAMIXUnknownVariable >>> FAMIXGlobalVariable >>> FAMIXParameter >>> FAMIXAttribute >>> FAMIXImplicitVariable >>> (and more outside FAMIX core) >>> >>> but a code generator does not know that, so I have to implement the corresponding messages/methods by hand. That is a bit annoying since this really is very simple code that could easily be generated. >>> Example for one of the methods that have to be written by hand: >>> >>> FAMIXAttribute>>belongsTo >>> ^ self parentType >>> >>> >>> Every implementation of 'belongsTo' looks like that, i.e. is a very simple delegate, or let us call it an "alias". >>> >>> I suggest to add the information about such "aliases" to the pragmas: >>> >>> 1) add <alias> to NamedEntity>>belongsTo >>> 2) add <aliasedBy #belongsTo> to all subclass properties, e.g. to FAMIXAttribute>>parentType >>> >>> >>> >>> Then, with that kind of information in an mse file, a code generator could do more work for me and I had time to drink an additional coffee or two :) >>> >>> And maybe metamodel browsers can profit from that kind of information, too. >>> >>> >>> Cheers, >>> Raffael Krebs >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "To lead is not to demand things, it is to make them happen." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Don't give to get. Just give." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |