22 Jun
2010
22 Jun
'10
12:47 a.m.
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
22 Jun
22 Jun
7:42 a.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
9:15 a.m.
On Tue, 2010-06-22 at 07:42 +0200, Tudor Girba wrote:
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
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.
1:44 p.m.
Hi,
On 22 Jun 2010, at 09:15, Ross Boylan wrote:
On Tue, 2010-06-22 at 07:42 +0200, Tudor Girba wrote:
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
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. Ross
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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."
9:36 a.m.
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
5229
days inactive
5230
days old
4 comments
2 participants
participants (2)
-
Ross Boylan -
Tudor Girba