Subj : Re: Compacting JS source via ParseTree or Decompile
To   : Dan Libby
From : Brendan Eich
Date : Sun Jun 06 2004 10:44 am

Dan Libby wrote:

>  - ability to pretty print source *with comments*. This doesn't seem to 
> be possible decompiling from bytecode, correct?  From JSParseNode?

You'll need to extend the front end to keep comments.  Currently the 
scanner strips them.

>  - Finer grained control over formatting: more indentation and newline 
> options, positioning of curly braces and parens, braces ommitted for IF 
> with single statement.  Rather than hard-code this type of logic into 
> the JS library JSPrinter, it seems like these behaviors could be 
> controlled by the calling application via callbacks.

This is not the sort of overhead or code complexity the engine wants for 
general web browser, VXML service, etc. embedding, where performance and 
code footprint matter.

I'd suggest writing a separate back end based on the front end data 
structures, *if* we can agree on how to preserve indentation, comments, 
unnecessary braces, etc. in the common front end.  We might end up using 
ifdefs to preserve perf and footprint.

>  - auto-generation of comment templates (stubs) for functions/methods, 
> including function name and params.  For this, the app would need to be 
> able to introspect the function/class and insert the comments into the 
> string at approprate places.

What do these templates look like?  Are they just for documentation, or 
for other purposes?

> I am still interested in the "walk pn and check sanity" approach, which 
> seems like it might enable some of the features listed above.  However, 
> I'm having trouble making sense of the JSParseNode struct.  And looking 
> at the function js_EmitTree() is quite intimidating.  Do you see a 
> simple way for me to walk the PN and emit the [possibly modified] source 
> code, or am I getting in too deep for a weekend project?

It depends on how much you know the engine, but let's design first.

/be

.