FAMIXSourceAnchor
Locked
 
|
I want a way to represent where in the source code something came from.
FAMIXSourceAnchor looks as if it might be intended for this, but its only attribute, entity, apparently refers to another FAMIX entity, not to the source code. But perhaps entity is supposed to be a FAMIXFile or method source? It doesn't appear that FAMIXSourceAnchor is used, even though every FAMIXSourcedEntity can have one. Can anyone provide more info on what FAMIXSourceAnchor is supposed to be doing? There is no class comment. Second, every FAMIXSourcedEntity has a comments attribute. This seems a mixed blessing, since the attachment of comments is often ambiguous. For example, in SAS one might have data a; x=34; /* a very silly example */ data b; y=1; It's unclear whether the comment applies to the data a or data b step. If you're a parser, it might also apply to 34, x=34, data, or data b. Third, I'm probably going to need a richer concept of source location. SAS allows inclusion of other files in the source code (like #include for C) and also has a macro processor, which may expand out a macro and discover more macros that it recursively expands. Comments? Ross _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
> I want a way to represent where in the source code something came > from. > > FAMIXSourceAnchor looks as if it might be intended for this, but its > only attribute, entity, apparently refers to another FAMIX entity, not > to the source code. But perhaps entity is supposed to be a > FAMIXFile or > method source? It doesn't appear that FAMIXSourceAnchor is used, even > though every FAMIXSourcedEntity can have one. > > Can anyone provide more info on what FAMIXSourceAnchor is supposed > to be > doing? There is no class comment. FAMIXSourceAnchor is an abstract superclass of actual anchors. Please take a look at the two existing subclasses, FAMIXFileAnchor (points to a position in a file) and FAMIXSourceTextAnchor (stores directly the text). > Second, every FAMIXSourcedEntity has a comments attribute. This > seems a > mixed blessing, since the attachment of comments is often ambiguous. > For example, in SAS one might have > data a; > x=34; > /* a very silly example */ > data b; > y=1; > > It's unclear whether the comment applies to the data a or data b step. > If you're a parser, it might also apply to 34, x=34, data, or data b. I am not sure what the question here is :). Your problem seems to be related to a convention in the language you are parsing. The same situation exists in Java for method comments. If we would have your example, the parser will decide that your comment belongs to the second method. > Third, I'm probably going to need a richer concept of source location. > SAS allows inclusion of other files in the source code (like #include > for C) and also has a macro processor, which may expand out a macro > and > discover more macros that it recursively expands. If you need a different source location than what already exists, you should subclass FAMIXSourceAnchor. As you noticed, as an abstract class it only provides the link to the entity, and your subclass can provide the info for the actual location. Cheers, Doru > Comments? > > Ross > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Sometimes the best solution is not the best solution." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Tue, 2010-06-22 at 07:42 +0200, Tudor Girba wrote:
> > Second, every FAMIXSourcedEntity has a comments attribute. This > > seems a > > mixed blessing, since the attachment of comments is often ambiguous. > > For example, in SAS one might have > > data a; > > x=34; > > /* a very silly example */ > > data b; > > y=1; > > > > It's unclear whether the comment applies to the data a or data b > step. > > If you're a parser, it might also apply to 34, x=34, data, or data > b. > > I am not sure what the question here is :). Your problem seems to be > related to a convention in the language you are parsing. The same > situation exists in Java for method comments. If we would have your > example, the parser will decide that your comment belongs to the > second method. comments to be associated with specific modeled entities. The implicit comment is that, in the case of code I'm dealing with, there's no way the parser will be clever enough, or the input regular enough, to make such association reliably. Ross _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
On Tue, 2010-06-22 at 07:42 +0200, Tudor Girba wrote:
> FAMIXSourceAnchor is an abstract superclass of actual anchors. > Please > take a look at the two existing subclasses, FAMIXFileAnchor (points > to > a position in a file) and FAMIXSourceTextAnchor (stores directly the > text). Thanks for the pointer (I guess that's a pun). FamixSourceTextAnchor>>source has no annotation. Is that an oversight? The same class also has methods (e.g., #lineCount) that do not correspond to instance variables. I think my understanding of what these classes are suppsed to be is still shakey. I thought they were basically bags of properties, an excuse to provide method and class annotations. Could anyone offer any refinements? Thanks, Doru, for all your answers so far. Ross _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Ross Boylan
Hi,
On 22 Jun 2010, at 09:15, Ross Boylan wrote: > On Tue, 2010-06-22 at 07:42 +0200, Tudor Girba wrote: >>> Second, every FAMIXSourcedEntity has a comments attribute. This >>> seems a >>> mixed blessing, since the attachment of comments is often ambiguous. >>> For example, in SAS one might have >>> data a; >>> x=34; >>> /* a very silly example */ >>> data b; >>> y=1; >>> >>> It's unclear whether the comment applies to the data a or data b >> step. >>> If you're a parser, it might also apply to 34, x=34, data, or data >> b. >> >> I am not sure what the question here is :). Your problem seems to be >> related to a convention in the language you are parsing. The same >> situation exists in Java for method comments. If we would have your >> example, the parser will decide that your comment belongs to the >> second method. > The implicit question is whether this framework forces or encourages > comments to be associated with specific modeled entities. The > implicit > comment is that, in the case of code I'm dealing with, there's no way > the parser will be clever enough, or the input regular enough, to make > such association reliably. I still do not understand :). The framework does not force anything in this regard: you can choose where you want the comment to be attached. In your case, you could simply attach the comments to the container entity. Cheers, Doru > Ross > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ 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 |