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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
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.
Ross
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
-
Ross Boylan -
Tudor Girba