Some questions before approval:

You're checking for "(" so that
  xx;
  (yy)
is not joined as xx(yy), right?
But don't we have the same problem with
  xx;
  -yy
Since expression statements can be arbitrary expressions.  Looks like
unary plus (xx; +yy) might have the same problem. Granted these would be strange to encounter in the wild, but I'm wary of the special case - especially when
I'm not sure there aren't others.  Or am I missing something?

Nit:
      this.SEMI = ";" + (compress ? SPACE : NEWLINE);
would probably be more readable as
      this.SEMI = ";" + (compress ? "" : NEWLINE);

- Don

On Nov 28, 2007, at 1:49 PM, P T Withington wrote:

Change 20071128-ptw-S by [EMAIL PROTECTED] on 2007-11-28 13:17:43 EST
    in /Users/ptw/OpenLaszlo/ringding-2
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Don't try to be so cute about using implicit semicolons in
    Javascript compiler

Bugs Fixed:
LPP-5130 'resources in DHTML fail with "is not a function'" error'

Technical Reviewer: [EMAIL PROTECTED] (pending)
QA Reviewer: enw (pending)

Details:
    We used to try to be clever and use newlines in place of
    semicolons in our 'compressed' code so that the code was a little
    more human-readable (and debuggable, using the native browser
    debugger).  But this cuteness was just broken and caused some
    expressions to not be interpreted as statements (and often to be
    interpreted as function calls).  Without a huge amount of work, it
    is difficult to correctly compute where an implicit semicolon can
    be used.

    Instead, we now always end a statement with a semicolon and only
    elide them before the close brace of a block (which is easily
    computable).  And, we output blocks a little more compactly,
    actually improving the 'compression' of our Javascript output.

    The primary change is to remove the old heuristic that inserted
    semicolons in between statements in a statement list, and to
    explicitly append one to each statement.  Put all the block
    building in one method instead of inlining it all over the place.

Tests:
    smokecheck, test case in bug, lzmail in DHTML now gets past the
    reported error

Files:
M      WEB-INF/lps/server/src/org/openlaszlo/sc/Compiler.java


Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20071128- ptw-S.tar


--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

Voice:  617-547-7881
Email:  [EMAIL PROTECTED]
WWW:    http://www.ddanderson.com

Reply via email to