[e-lang] quick look at Caja vs. GWT's output

[Lex Spoon]

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  
>> with
>> having GWT target Caja instead of arbitrary JavaScript.  In  
>> general, GWT is
>> using JavaScript to simulate Java, so rules like "this stealing" and
>> 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  
statically.

The restrictions on a static instance method $A$foo would be things  
like:

	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)
> has both public and non-public fields and methods. JavaScript has both
> 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.)

Okay.


In my next time slice I'll check up on the Cajita mixin pattern.   
I've been meaning to study it anyway.


-Lex