Tracing through type-printer.js
In my first attempts of creating a minimal testcase I reported everything worked as it should. However at the time I didn’t realize that in type-printer.js (the possible source of the FPPP) the Dehydra function process_type(type) was used exclusively. Using process_type() keeps everything together and has all needed type information. I had been using other Dehydra functions to generate similar output, but this would be a huge problem going through as much code a type-printer.js does.
Since I wanted to see the code (problem) in progress I decided to trace the data route through type-printer.js so I could get what I wanted directly:
| Function: | Variable/list/call: |
| 1) process_type(t) | t |
| 2) interestingType(t) | t name = t.name typeList[name] += t |
| 3) input_end() | p in typeList dumpType(typeList[p]) |
| 3.1) dumpType(t) | t members = m in publicMembers(t) |
| 3.1.1) publicMembers(t) | t Base in publicBases(t) |
| 3.1.1.1) publicBases(t) | t base in t.bases base.type |
| 3.1.1) publicMembers(t) (return) | member in base.members |
| 3.1) dumpType(t) (return) | m in members p in m.members typeName(p.type) |
| 3.1.2) typeName(t) | t |
In other word what I am looking for *should* be visible at “t.bases.type.members.parameters.type”. Yet it seems my test code doesn’t generate a “path” like this, and I wonder where I might have gone wrong. One possible reason I might have miscounted is because I was often Thrown through a loop with the JavaScript 1.7 additions… Literally, a loop.
I would much rather watch the flow through a debugger, which I am attempting to do now. A post on the should be up soon. It is (hopefully at least) half written and waiting for me to figure out the second half.
April 5, 2010 at 7:09 am
You should get yourself syndicated on Planet Mozilla; there are cool things being written about here.