I'd prefer to just modify ScriptRuntime.toObjectOrNull signature to
take a "Scriptable topLevelScope" argument, and then propagate the
change through the code. Is that not sufficient?
Attila.
On 2008.11.12., at 10:48, Marc Guillemot wrote:
Hi all,
as far as I know, it isn't explicitly documented anywhere how Rhino
exposes JavaScript primitives.
Current implementation exposes types as follows:
JS String primitive -> java.lang.String
JS Boolean primitive -> java.lang.Boolean
JS Number primitive -> mostly as java.lang.Double but not consistently
(see bug https://bugzilla.mozilla.org/show_bug.cgi?id=367692)
As described in bug #374918
(https://bugzilla.mozilla.org/show_bug.cgi?id=374918), these java
types
are not appropriate to represent JS primitives correctly because they
don't allow to store any information on the attached scope. This means
that we have to use new classes, lets say for instance
PrimitiveString,
PrimitiveNumber and PrimitiveBoolean that hold both the value and the
scope to fix the problem. This requires significant changes but this
works.
The problem with this PrimitiveXxxx change is that it is automatically
visible to Java host objects, at least in following cases:
- methods accepting an Object as parameter
- methods accepting an Object[] as parameter
in the other case it is probably possible to hide the details of the
implementation and to get the java.lang.X from the PrimitiveX.
Now my question:
is it a change that can be imposed to Rhino users or has this design
error to remain here for ever to avoid breaking existing code?
Of course, I'd prefer the first way as I'd really like to see this bug
fixed ;-)
Cheers,
Marc.
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
