Made treehydra and dehydra make use of js prototypes

RESOLVED FIXED

Status

()

Core
Rewriting and Analysis
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: (dormant account), Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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.

http://hg.mozilla.org/users/tglek_mozilla.com/dehydra-mq/?file/527161d02cab/pretty_prototype.diff

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.
(Reporter)

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
(Reporter)

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.

(Reporter)

Comment 6

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