Made treehydra and dehydra make use of js prototypes




Rewriting and Analysis
10 years ago
10 years ago


(Reporter: (dormant account), Unassigned)


Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




10 years ago
dmandelin kept complaining about mysteries of objects, especially ones produced by treehydra, so I caved in. Here is my first stab at improving the situation.

The idea here is to make JavaScript nodes self documenting by implementing custom .toString() methods that would carefully filter content and by default not produce giant blobs of stuff as they do currently.

In addition treehydra nodes will have the GCC macros folded into their prototypes so ideally we'll end up with a super easy to understand interface to the GCC AST and end up with best of both worlds: low level details and pretty API.

Comment 1

10 years ago
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?
Blocks: 420933

Comment 4

10 years ago
Dave, can you post the patch you use for this for review? I recall you added some more prototype funcs.
Blocks: 423898
(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.


Comment 6

10 years ago
Should open a new bug for any further improvements
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.