RFE: class binding optimizations for non-inheritance cases

[GoogleCodeExporter]

The class-binding API holds an internal JS-to-native mapping which is used 
to perform type-safe conversions between JS and C++. It allows us, e.g., to 
safely convert (or safely fail to convert) between the two without relying 
on any sort of casting. This feature is also important when implementing 
cross-JS/Native inheritance. However, it has a nontrivial memory cost and 
is a bit of a performance causes a slight performance hit.

For bound classes where inheritance is not an issue (i.e. they don't 
inherit another bound class and no JS-side class will/should inherit them), 
we should have an option which optimizes out the lookup table and instead 
uses direct casts (which is the v8-official way of converting classes).

One approach to this was introduced in r741 (edge branch), but it needs 
significant testing before it is deemed usable.

Original issue reported on code.google.com by sgbeal@googlemail.com on 17 Oct 2009 at 9:22

[GoogleCodeExporter]

i just discovered that the experimental code for this also breaks automatic 
conversions to/from (T*) in function args and return types.

The point being only that this isn't yet ready for use.

Original comment by sgbeal@googlemail.com on 17 Oct 2009 at 10:14

• Changed state: Started

[GoogleCodeExporter]

doh, bad news: if we disable the type mapping we _cannot_ convert from native 
to JS 
because the native has no notion its associated a JS object. This is why such 
bindings 
fail to convert (T*) arguments. Not all bound types need such a conversion.

So the current code (not yet committed) will throw a JS-side exception if 
NativeToJS() 
is ever called for a "shollow-bound" type. i'd like to make this a compile-time 
assertion, but need extra infrastructure to support that.

Original comment by sgbeal@googlemail.com on 17 Oct 2009 at 10:32

[GoogleCodeExporter]

Current status:

- The new binder is almost 100% controlled via policy classes (T-specific
specializations of various structs). The only part which still needs to be 
factored
out is the "wrap" part (that is, connecting with the Persistent bits).

- It currently does only shallow binding. A deep-binding policy still needs to 
be
developed (based on the WeakJSClassCreator bits).

- JS-to-Native casting works, but Native-to-JS cannot be done for the generic 
case
(this is now a compile-time assertion). Native-to-JS requires "deep binding", 
which
isn't yet implemented in the new code.

- It is possible to bind members and run them, but there are currently no 
convenience
routines for doing so. i still need to write one more layer of proxy templates
(porting them over from ClassBinder) before that can be finished up.

- Seems to work but needs more testing and much more fleshing out.

it'll be another few days before i commit this; i don't want to pollute the 
tree with
these 4 or 5 temporary files.

Original comment by sgbeal@googlemail.com on 20 Oct 2009 at 2:14

[GoogleCodeExporter]

The new ClassWrap binding mechanism defaults to using as little trickery as it 
can
internally get away with. It does not do any sort of deep binding by default 
now, so
it defaults to "fast and mostly safe" and can be made "slow and typesafe" via 
policy
additions.

Original comment by sgbeal@googlemail.com on 29 Oct 2009 at 4:48

• Changed state: Fixed