[e-lang] quick look at Caja vs. GWT's output
lex at lexspoon.org
Thu Jan 24 11:55:20 EST 2008
On Jan 22, 2008, at 7:58 PM, Mark Miller wrote:
> 2008/1/22 Lex Spoon <lex at lexspoon.org>:
>> From my quick read of the Caja doc, I see no fundamental problems
>> general, GWT is
>> inheritance rules should not be a problem.
> Is there any general summary of the GWT translation? I'm especially
> curious about GWT's translation of Java's 'super'.
Good question. It looks a bit different from what is in Cajita, but
maybe it doesn't need to be. Also, I thought of a new problem while
considering this: nested classes. See below.
The GWT approach is based on a general system of statically resolved
method calls. It includes static calls anyway for performance
reasons, and so it uses that same mechanism to handle super calls.
For the case of super.foo(this), GWT emits $foo(this), where $foo is
the appropriate target method.
For GWT -> Caja, this should not be a big deal. At worst, all fields
can be marked public, and the $foo functions can be thought of as
regular old top-level functions.
For a sensible Joe-E -> Caja translation, though, there is the issue
that these top-level functions should only be called on the
appropriate object. The optimization can be mostly disabled if need
be, but that does not help for super calls. For super calls, and
possibly other circumstances, a way out might be to loosen up Caja to
allow "static instance methods", methods that have a "this" but that
are called without run-time dispatch. Caja functions named $A$foo
could be thought of as instance methods of A that are called called
The restrictions on a static instance method $A$foo would be things
1. They must be defined before A is frozen.
2. They may only be called in yet-to-be-defined circumstances that
at least include super calls.
3. If the first argument of the function is named this$static, then
the caller must pass "this" in as the first argument.
4. In the body of $A$foo, all Caja rules regarding "this" instead
apply to "this$static".
Another issue comes up here: Java has nested classes, and GWT
supports them. Thus in general there is a chain of this's that are
accessible from any method. So for the last two rules, there can
actually be a string of "this$static" arguments (this$static, this
$static$1, ...), each corresponding to a different enclosing object.
I'll put it on my list to give the Cajita inheritance pattern a good
consideration. I wouldn't be surprised if GWT could be at least have
an option of generating the pattern as it stands. As far as I know,
however, the performance argument is real, and so it would be nice
but not essential if Caja can support static instance methods.
>> [...] Also, all fields will probably need to get automatic
>> getters and
>> setters, because GWT input is arbitrary Java code.
> I don't understand about getters and setters. Java (as well as Joe-E)
> properties used as fields and properties used as methods. In Caja,
> properties can be public or non-public. So why would you need to
> generate getters and setters that weren't in the original Java?
I didn't realize that Caja had public, mutable properties. That
certainly simplifies things. Nonetheless, some private fields in
Java code might need to get turned into public fields, due to how
super is handled right now.
For sensible Joe-E support, probably no private fields should be
exposed, so things are trickier.
>> [...] The first thing, it would seem,
>> is to check whether GWT can be coaxed into emitting Caja at all.
> That sounds great! (I'm also curious about whether it would make any
> sense to get GWT to emit Cajita, but that's much lower priority.)
In my next time slice I'll check up on the Cajita mixin pattern.
I've been meaning to study it anyway.
More information about the e-lang