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.

Advertisement