jooc Bugs and Feature Requests
==============================

Fixed Bugs:

* Switch statement does not seem to be working
  inside of a loop.
  Throws assertion failure during analyze.
  Example:
  while (true) switch(true) {};
  Error:
  Assertion failed: loopStatement == getCurrentLoopOrSwitch()
  Workaround: use many if-s or put switch into helper function.

* empty initializer in for statement throws NPE
  during analyze.
  Example: for ( ; i<=n; ++i) ;
  Error: NPE
  Workaround: do not leave empty, or use while.

* function statements inside methods do not allow
  a name. Naming functions may be helpful for
  documentation and debugging purposes.
  Example:
  public function foo() {
    return function xxx() { return "bar"; };
  }
  Error: expected '(', not identifier
  Workaround: place the name in comment brackets
  (not a workaround for debugging).

* code in a static block may not use function
  statements as parameters.
  Example:
  static {
    foo(function() { return "bar";});
  }
  Error:
  Assertion failed: Parameters must not have any modifiers
  Workaround: in the static block, call a static
  function. There, function parameters work.

* "static function" (without modifier public etc.) is
  rejected as syntactically incorrect.

Known Bugs:

* the debug option -g apparently should support different
  debug options (-g:<option>), but the code is buggy.
  The option string is actually never used, only its presence
  is checked.
  Thus, without option string, only debugLines is on,
  with any option string, all debug options are on.

* divided-by ("/") is sometimes mistaken for a reg-exps
  (TODO: find example!).

* The compiler disallows on-the-fly object creation in
  ?: expression.
  Example:
  var x = b ? { p: 1 } : { p: 2};
  Error:
  Syntax error: '{'

Implemented Feature Requests:

* Option to keep just the constructor function's name,
  not the name of all members. The name of the constructor
  function could then be used as the class name.

Open Feature Requests:

* Support for abstract methods and interfaces:
  Standard JavaScript instanceof works by structure checking.
  An interface should be compiled into a class implementing
  each method by throwing an AbstractMethodException.
  So should abstract methods.
  Whether the actual "implements" check is done at compile
  time or at run time is still open. JsUnit does it at
  run time, but then, they don't even have a compiler...

* When implementing a type checker, allow an expression
  after new, combined with a type cast. This is necessary
  for "reflective" programming.

* Option to provide StackTrace support: For each method,
  code would be generated that pushes the method call
  (class/method name, parameters?) to a global call
  stack. The following Java-like methods would make
  sense: Thread.dumpStack(), exception.printStackTrace().

* Provide integration with Firebug/Firebug lite.
  This way the logging can be directed to Firebug's
  console.
  I.E.: console.log("Log Entry...")
  This is much nicer than the awkward looking floating 
  window.  

Dropped Feature Requests:

* Hide types in comments: In order for IntelliJ IDEA to
  not get confused with our JavaScript class syntax,
  types should be hidden in comments starting with a
  colon, e.g.
    public function foo(x /*:String*/) /*:void*/ ...
  The parser should be adapted to recognize /*: as
  a special comment and treat the contents as the type.
  Thus, joodoc would not have to be adjusted and could
  still show the intended types in the HTML documentation.
  The compiler does not use the types, anyway.
  Alternatively, we could write a preprocessor that
  removes all /*: comments before compiling.
=> Implemented enhanced IDEA-JavaScript language mode
   that accepts type annotations!
