> On Nov 3, 2016, at 11:46 AM, stepharo <[email protected]> wrote: > > >> A comment isn’t code. The nodes are for code. A comment is more like a token >> — RBComment basically has the same two instance variables as RBToken. Should >> tokens also be nodes? For example, should a left paren token be represented >> as a node? >> >> If a comment is a node, how is it visited? >> For example, if you have (“comment1” self “comment2” foo: “comment3” a bar: >> “comment4” b “comment5”), what is the traversal order for the nodes? > To reproduce the code as it was typed why the representation a message is not > a sequence. because you need to encode that you > have comment1 and self and comment2
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. > 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. 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. 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. >> 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. John Brant
