I committed the initial stuff. I think I'll keep existing GCC macro names but start folding them into the prototype lowercased TREE_CODE(foo) -> foo.tree_code(), etc. I think for now I'll keep the TREE_CODE version for backwards compatibility.
I think I used a couple of these things, especially .operands, but I guess it's not self-documenting enough yet for it to be easy to notice what the new features are. Anyway, I just wanted to kick out a few random thoughts while the design is still firming up. - Would be nice to use property accessors instead of methods where it makes sense. - The properties that it makes sense to access depend on the node type. So it's a little weird to have methods put on the prototype for everything (although it does make sense in some cases, like toString). But the issue's kind of complicated. Do we want to have separate prototypes for each TREE_CODE? Or maybe just each TREE_CODE_CLASS? And we might consider doing some of it through unhandledLazyProperty. - For properties we add, it might be fun to include a doc string, so that you can do stuff like "node.doc('operands')" or some such.
I'm using some of these features in my outparams scripts, so that can't land until this does. Or, I could stop using those features. I think .operands is the main one I use. What do you think?
Dave, can you post the patch you use for this for review? I recall you added some more prototype funcs.
(In reply to comment #4) > Dave, can you post the patch you use for this for review? I recall you added > some more prototype funcs. No, AFAIK I didn't modify treehydra.js or add more prototype functions.
Should open a new bug for any further improvements