"Scriptable target" argument to Ref.(get|set|has|delete) methods. The idea was
to optimize away in many cases creation of Ref instances, but given that modern
JVM can GC short-lived objects efficiently it does not sound right to have code
complexity now in the hope of slightly more efficient implementation later.
1. IdScriptableObject.maxInstanceId is replaced by overridden getMaxInstanceId()
2. BaseFunction.argumentsProperty is replaced by storing when necessary explicit "arguments" property in ScriptableObject hashmap.
3. NativeFunction.(argNames|argCount|version) is replaced by code that reconstruct the necessary values from embedded in class file or InterpreterData (see bug 264637)
References now are represented by the pairs (ref, ref_target) where ref is Ref (former Reference) instance and ref_target is Scriptable to apply the reference for.
To return the pair from Reference creation function Context.scratchRefTarget is used to store the target part.
This change allowed to extend XMLName from Ref eliminating the need for XMLReference.
I changes just added toObject(Contetx cx, Object obj) to
toObjectOrNull(Contetx cx, Object obj) which returns null when obj is undefined
or null. It forces the caller to check to the return status but then much
better error report can be generated since the caller knows the operation that was called upon the undefined or null value.
To implement the function call redirection functionality XMLObject.getExtraMethodSource is added() to return an additional object to use as method source.
List of the affected files:
mozilla/js/rhino/src/org/mozilla/javascript/Callable.java
mozilla/js/rhino/src/org/mozilla/javascript/ClassCache.java
mozilla/js/rhino/src/org/mozilla/javascript/CompilerEnvirons.java
mozilla/js/rhino/src/org/mozilla/javascript/ContextAction.java
mozilla/js/rhino/src/org/mozilla/javascript/ContextFactory.java
mozilla/js/rhino/src/org/mozilla/javascript/Kit.java
mozilla/js/rhino/src/org/mozilla/javascript/Reference.java
mozilla/js/rhino/src/org/mozilla/javascript/SpecialRef.java
mozilla/js/rhino/toolsrc/org/mozilla/javascript/tools/debugger/GuiCallback.java
mozilla/js/rhino/toolsrc/org/mozilla/javascript/tools/debugger/test.js
mozilla/js/rhino/xmlimplsrc/org/mozilla/javascript/xmlimpl/XMLReference.java
Please contact igor@runitsoft.com if you have any questions about this.
Signatures in Reference are changed to include Context and reference-related methods in ScriptRuntime accept/return explicit Reference type instead of generic Object as code generation ensure proper type.
2. x..y use explicit reference instead of special descendants mark XMLName:
In this way less code is necessary to support x..y operations and support for .. in non-xml objects is possible.
to check for strict mode.
2. Fix name lokup bug in XMLReference that caused in cases like
foo.(@bar == 'something') to throw runtime exception if bar attribute
does not exist in foo.
JavaSriptException now inherits from RhinoException which inherits from RuntimeException and as such it does not necessary to declare it.
Moreover, it is wrong to use it for the documentation purpose since a script can also throw EcmaError and WrappedException and a proper documentation would require to document those exceptions as well. But since almost all Rhino functions can potentially execute script code it means that wast majority of functions would bear the declarations, not only code overriding or calling explicitly Function.call/construct. And then the throw declarations would bring no information if it always would be "throws RhinoException". Thus it is better not to litter sources with the declarations at all.
2. xml/XMLObject do not define lib() method and instead defines few abstract methods to create "with" proxies and perform addition.
3. XMLLib implementation is stored in the scope using ScriptableObject.associateValue() and does not depend on presence of proper XML object.
ScriptRuntime.get(Name|Prop|Elem|Value)FunctionAndThis provides uniform way to get function object and its this during function calls. It allowed to simplify handling of method calls both in interpreter and optimizer and opened a way to implement independent processing of function and property namespaces.
it has to be updated. This is done for Rhino classes and since IdScriptable
is not a part of public API, it should not matter. But in reality someone can
subclass IdScriptable in application code.
To help with upgrade in such cases I renamed IdScriptable into
IdScriptableObject. In this way the application using IdScriptable code can add
old IdScriptable class to its CLASSPATH and be able to run again without the
need to recompile/change anything in the source.
inonit%inonit.com
gerv%gerv.net
szegedia%freemail.hu
igor%mir2.org