Here are my thoughts: 1) Personally this doesn't make a difference to me as, in my app, scripts don't have access to java objects, but for those that do, it seems like it makes sense.
2) I'm jumping up and down in my chair for this one. Assuming it means that the get/put operations currently implemented on ScriptableObject and its subclasses will be reviewed and cleaned up. The current implementation is not consistent from one subclass to the next (as described in bug #464312). I think the work that would be required for this one would also naturally resolve the issues described in bug #464312, and in the end we would have a more elegant implementation. Just make sure that NativeArray implements/overrides the interface in a way consistent with other subclasses and I'll come give you a kiss! 3) This should be an option that can be enabled or disabled, but I agree with it on the basis that many implementations will never allow access directly back to the java classes, so there is no need to restrict java reserve words in those apps. My two/three cents. David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] a.org] On Behalf Of Hannes Wallnoefer Sent: Thursday, November 13, 2008 4:01 PM To: [email protected] Subject: Feedback wanted on new features These are some features that I'm quite excited and sufficiently confident about, but I'd like to hear some other opinions about before committing. https://bugzilla.mozilla.org/show_bug.cgi?id=462827 - Do not wrap JavaAdapter that implement Scriptable This is a very clever (and small) hack to not wrap JavaAdapters when the class implements org.mozilla.javascript.Scriptable. The allows to extend JS objects from within JavaScript very easily and elegantly. The bug has an attached demo script that shows how this can be used to implement a "JSAdapter". I can't think of any contraindications, i.e. cases where you'd want to handle a Scriptable object as Java object. https://bugzilla.mozilla.org/show_bug.cgi?id=448816 - Implement Map interface in ScriptableObject This allows ScriptableObjects to be accessed as java.util.Map from Java. The current implementation is somewhat limited as put() is not supported. It also doesn't implement equals() and hashCode() as suggested by the java.util.Map API, as making these dependent on the object's properties might easily break existing code. Even so, this should be very useful to move data between JS and Java. https://bugzilla.mozilla.org/show_bug.cgi?id=461122 - Allow future reserved words as identifiers by default Not being able to use any Java reserved word in JavaScript has been one of my pet peeves. By now, all browser JS engines I know about allow the use of future reserved words as defined by EcmaScript 7.5.3, and I think Rhino should catch up with them. The patch also allows use of "import" and "export" which are still reserved in Spidermonkey, but have no special meaning in Rhino. What do you think? Hannes _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
