Comparison of JSAdapter and JOMP

5	* Inheritance not as easyeasy as with plain JS objects. Normal use needs wrapped object, but for prototype use in inheritance chain we need unwrapped adaptee object,. so As a result we need two constructorsseparate constructors/factory methods for the wrapped and unwrapped object, or wrap the object manually.
6	* getDefaultValue is forwarded to the adaptee object, so a toString() that relies on adapter functionality won't work. This is rather easy to fix.
9	* Adds a burden overhead to all property access methods of the default JS object.
10	* Not thread-safe,. and making Making it threadsafe will would probably require using a java.lang.ThreadLocal to disable the metaobject during invocation, which would put an even bigger penalty burden on the default JS object.

1	This is a comparison of JSAdapter JSAdapter\|http://blogs.sun.com/sundararajan/entry/self_javascript_and_jsadapter and JOMPJOMP\|http://www.bias2build.com/thesis/javascript_mop_expanded.html, two approaches to add metaprogramming features to Rhino.

11	* Not thread-safe, and making it threadsafe will put a burden an even bigger penalty on the default JS object.

1	This is a comparison of JSAdapter and JOMP, two approaches to add metaprogramming features to Rhino.
3	=== JSAdapter
4
5	* Inheritance not as easy. Normal use needs wrapped object, but for prototype in inheritance chain we need unwrapped adaptee object, so we need two constructors.
6	* getDefaultValue is forwarded to the adaptee object, so a toString() that relies on adapter functionality won't work.
7
8	=== JOMP
9
10	* Adds a burden to all property access methods of the default JS object.
11	* Not thread-safe, and making it threadsafe will put a burden on the default JS object.
12
13	=== Test code
14
15	This is a script that implements a base and extended object using both techniques, and a patch for adding JOMP support to Rhino.
16
17	<% this.attachments %>