2007-07-25 21:48:54 UTC
hi again
two parse solution: well, yes and no. i agree it's probably necessary to make two passes over the input files for that purpose to keep the solution scalable to large code bases. however, i'd prefer a solution with one parser syntax for two reasons: 1) better to maintain. 2) change the parser syntax to build an in-memory model of the java file at hand. from this memory model we should understand, what the code actually does/mean and then generate the corresponding html. intermingling this task with the actual parsing process as is the current state, will make maintainability harder as new features will be added, as it interferes with the parsing and so on. in this way we would also be better off in correctly supporting nested/inner classes and generics arguments as we could add these one by one independent of everything else. this would be quite a refactoring however ...
error recovery: from my point of view, there's not too much reason to invest a great effort into this. when using the tool as a documentation help, we can assume that the source code being processed is valid and compilable (of which javac makes a pretty good job). which actually makes it unnecessary to provide error handling, imho.
accepting invalid code is never a good thing ... as the source code is the only valid reference of any software system ... ;-)
i'm currently very busy and won't have too much time for big time action, sorry. i'll be happy to help out as much as i can, can't promise anything however.
cheers so far
leon
