But how does this fit with a tree structure. For example, should “comment5” be
associated with the “b” variable node, or the #foo:bar: message, or the
sequence node that contains the #foo:bar: message, or the block or method node
that contains the sequence node. You can choose, but only the writer of the
comment can tell if you are right.
How tokens solves this problem?
I think that we do not really care one objective is to be able to
recreate the code from the tree. I worked on a project in C
where the guys want to know if the code is well commented and we built
heuristics to associate the comments to the closest node.
We do not have a structure that is responsible for that order.
We could have two entries in AST node;
one discrete where you can cherrypick what you want receiver arguments
selector
and one that represent the node placement.
Now when we emit bytecode comment would do nothing.
How having them as token helps? You will visit the receiver and check if it has
a token and place it.
I found that strange that comments are not part of the code tree as first class
citizen.
Tokens are essentially what they are now — although they aren’t in the RBToken
hierarchy. So far, the only advantages that I’ve heard you mention for nodes
are visiting nodes and having a parent. The example above shows why neither of
these are valid — you can’t determine what is the correct parent for the
comment.
Anyway, I think comments should not be in code, but rather on code. When you
add a comment, you would select a node or nodes that it applied to. When
viewing a method, the comment could be displayed inline (like we have now), off
to the side like reviewer comments in word processors, or a highlight that when
you move the mouse over would show in a popup.
Yes you are right.
Furthermore, there could be different comment types. For example, one could
have design comments, todo/review comments, example code comments, bug fix
comments, etc. The code view could be customized to show each one differently.
Comments could have pictures and other non-string items.
It would be really nice to have that.
I would put optional type declaration (and they should be optional).
Now for the main comment of a method I would not separate it because
this is too important.
Having comments as objects outside the method’s source string would allow them
to be easily searched. For example, someone could search for a certain bug fix.
Currently, if a bug fix id is in a comment, it requires a full text search of
all method text. This is slow. Therefore, many companies start adding these bug
fix ids to the code as symbols so that a senders search will work. I’ve seen
companies that put symbols like #Fix12345 as statements inside of methods.
However, this doesn’t work for Smalltalk’s that remove unused literals, so in
those cases they do something like adding a statement like #Fix12345 ==
#Fix12345 which generally isn’t optimized away.
:)
In addition to comments, I believe that annotations (not primitives) should be
on code instead of in code like they are now. With a good implementation one
could unify the concepts of comments and annotations.
Yes this is interesting.
Now the problem with annotations is that you have two kinds;
- the ones that decorate
- the ones that change or define the semantics (for those ones I
would not separate) them
Furthermore, if comments are nodes, how do they affect all of the code
rewriting and validation that is part of the RB and its rewrite tools
With comments cannot act as nullobjects for such operation?
Yes, someone could spend time making all of this work with the existing code.
However, why not fix the real problem in that comments and methods should not
be a single string, but rather objects.
Marcus did that during his phd and he blew up memory. So after we
got a guy that worked on tree compression but he never finished.
Because this is the part that makes all these ideas flying or not.
Anyway thanks for the discussion. It lets me think and I learn
something. I improved the class comment.
Because if it would have been good in the first place I would not even
ask the question.
John Brant
