Question: ScriptableObject implements the Map interface, but the Map.get impl. doesn't take into account the ScriptableObject prototype

[p-bakker]

So, if I have a JavaScript Object created like:

let p = {name: 'test'}
let c = Object.create(p);

And object c gets send to Java and the Java code tries to access the name property through the Map interface, it won't find it.

Is that the desired behavior?

Reason I'm asking is not so much that I need this behavior one way or another, but that I'm looking whether I can introduce an EcmaObject interface that follows the Object Internal Methods specification and the only method in ScriptableObject (which would implement the EcmaObject interface) that collides is Object ScriptableObject.get(Object id), which is part of the java.util.Map interface implementation.

The underlying reason of trying to get to this EcmaObject interface is easier implementation of new EcmaScript features (Template Literals, Proxy/Reflect etc.).

If there are any thoughts on this EcmaObject interface approach, besides the specific question about ScriptableObject.get & prototype, I'd appreciate it.

[tuchida]

ScriptableObject.getProperty traces the prototype.

rhino/src/org/mozilla/javascript/ScriptableObject.java

Line 2318 in b6e6af6

public static Object getProperty(Scriptable obj, String name)

[p-bakker]

Yeah, I know, but getProperty is not the part of the Map interface, so if in Java code you send this c value into some Java code that deals with Maps, it wont call getProperty, but get.

And yeah, the EcmaObject interface could instead define a getProperty instead of get, but then the naming is not inline with the spec (although the spec doesn't explicitly specify the name of the internal Object methods), which is just confusing imho.

[p-bakker]

Didn't explicitly state this before but the Object Internal [[Get]] method as defined by EcmaScript is to walk to the prototype chain (contrary to the current ScriptableObject.get(Object) or ScriptableObject.get(int/String/Symbol, Scriptable) implementations)

[tonygermano]

I don't think it should walk the prototype chain, since a Map is for holding data, and not representing objects. JSON.stringify also only looks at own properties.

I often use a javascript object to initialize a Map like:

var map = new java.util.HashMap({name: 'test'})

I would not want some property on Object.prototype to show up in the resulting Map.

The method you are looking for is probably one of the getObject* methods in ScriptRuntime.

[p-bakker]

I might be wrong, but I don't think your example applies here.

AFAICS, the ScriptableObject.get() method would only come into play when sending a JavaScript object {} from JavaScript land to the Java world and then the Java code would handle it as a Map en call .get(Object) on it.

Again, not sure, but I think if you'd send your map value back to Java land, it would just be a HashMap instance, not a ScriptableObject instance.

IMHO it would make sense if ScriptableObject.get(Object) would walk the prototype chain of the JavaScript object its called on from Java land: you don't want the logic on the Java-side to have to take into account that the Map instance is actually a JavaScript object that can have a prototype chain that you might need to walk to get to the value you're after.

[tonygermano]

I am sending a javascript object to java land by passing an object literal to the HashMap constructor, which expects a java.util.Map.

Like I said, ECMA [[Get]] is implemented by various functions in ScriptRuntime, rather than on ScriptableObject.

I know you were just looking at String.raw while working on #904 . If you compare the original code to what I ended up implementing, you'll see I changed the ScriptableObject.get calls to ScriptRuntime.getObjectProp and ScriptRuntime.getObjectIndex so that they would walk the prototype chain. I think I originally ran into the same issue as you until I discovered I was looking in the wrong place.

For what it's worth, I do agree with your change to the String.raw implementation.

[tonygermano]

Something else to think about is that we still need a get method that doesn't walk the prototype chain for various other features that require that.

[p-bakker]

I am sending a javascript object to java land by passing an object literal to the HashMap constructor, which expects a java.util.Map

Right, so wouldn't you expect your HashMap to contain name in the example below?

var p = {name: 'test'};
var map = new java.util.HashMap(Object.create(p))

I know you were just looking at String.raw while working on #904

My musings about ScriptableObject.get(Object) having to walk the prototype chain don't particularly come from String.raw impl. Besides me thinking it would just make more sense, I'm also trying to implement Proxies and having challenges because the implementation needs to be coded against the ScriptableObject class, instead of a particular interface, cause there's no interface that defines the (internal methods) of the EcmaScript Object Type.
So I'm trying to implement such interface (and trying to keep its naming as close to the spec as possible).
I think this is also helpful going forwards as it'll allow starting to organize Rhino's code more along the lines of the EcmaScript spec, making it easier to implement new features (and easier to grasp for devs).

Something else to think about is that we still need a get method that doesn't walk the prototype chain for various other features that require that.

The existing ScriptableObject.get(int/String/Symbol, Scriptable) methods wouldn't be removed

[tonygermano]

Right, so wouldn't you expect your HashMap to contain name in the example below?

var p = {name: 'test'};
var map = new java.util.HashMap(Object.create(p))

No, because Maps are for data, not inherited object properties. JSON.stringify(Object.create(p)) returns an empty object. Object.entries(Object.create(p)) returns an empty array.

My musings about ScriptableObject.get(Object) having to walk the prototype chain don't particularly come from String.raw impl.

The existing ScriptableObject.get(int/String/Symbol, Scriptable) methods wouldn't be removed

I was just trying to point you at some code that I knew we were both familiar with, and I think I had a similar journey as you. Various ScriptableObject.ecmaGet methods could probably be added that could refer to the ScriptRuntime methods.

[p-bakker]

No, because Maps are for data, not inherited object properties. JSON.stringify(Object.create(p)) returns an empty object. Object.entries(Object.create(p)) returns an empty array.

Right.... while in my opinion prototype properties could also be data (all depends how you're using it), I do agree with the examples of other methods (albeit all js land methods) and how they handle prototype properties.

So, assuming everyone else is of the same opinion, i have to just use some naming convention to differentiate these Ecma Internal Object methods.

What about using the exact names as used in the spec, so Get, GetOwnProperty, Set, etc? I know that's not the standard in java land, but it would make them stand out and not likely to clash with anything 🙂

If not that, what about prefixing with i (IGet) or e (eGet)?

[tonygermano]

why not ecmaGet? I think that makes it clear what the intended purpose is.

[p-bakker]

Crossed my mind as well, it just gets a bit long: ecmaDefineOwnProperty😀 But if that's the consensus, I'm fine with that

…

On Fri, May 21, 2021, 6:31 PM tonygermano ***@***.***> wrote: why not ecmaGet? I think that makes it clear what the intended purpose is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#903 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGADHKG67NXVMX34D35L3DTO2DHLANCNFSM45IXEO5A> .

[gbrail]

How about: 1. A class to hold all these, called something terribly clever like "EcmaRuntime" 2. Give each one a name that matches the name in the spec using Java naming conventions, so if the spec calls it [[Get]] then the name of the function is get(). Also, I suspect that many of these operations are already implemented in the codebase in various places, but likely with different names. There is lots of stuff in ScriptRuntime, for example, that purports to implement these things. There are also classes like IteratorLikeIterable which we wrote fairly recently to try and address these things. And, people use all these public methods outside Rhino because Rhino is embedded into thousands of projects. So, I'd suggest making really sure that we need new functions before writing them, and then if something already exists, that we document that so that it's easy to find later (perhaps add a comment that someone can grep for, for example).

…

On Fri, May 21, 2021 at 9:31 AM tonygermano ***@***.***> wrote: why not ecmaGet? I think that makes it clear what the intended purpose is. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#903 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I25FIXZYGGROR2R5PHTTO2DHLANCNFSM45IXEO5A> .

[p-bakker]

I have seen a lot of the logic already scattered around and it indeed needs careful deliberations. I don't quite understand your suggestion to put the methods in a class: I'm trying to define an interface to begin with. Once that's done, so in implementation of for example Proxy is not tied to the ScriptableObject implementation

…

On Fri, May 21, 2021, 6:48 PM Greg Brail ***@***.***> wrote: How about: 1. A class to hold all these, called something terribly clever like "EcmaRuntime" 2. Give each one a name that matches the name in the spec using Java naming conventions, so if the spec calls it [[Get]] then the name of the function is get(). Also, I suspect that many of these operations are already implemented in the codebase in various places, but likely with different names. There is lots of stuff in ScriptRuntime, for example, that purports to implement these things. There are also classes like IteratorLikeIterable which we wrote fairly recently to try and address these things. And, people use all these public methods outside Rhino because Rhino is embedded into thousands of projects. So, I'd suggest making really sure that we need new functions before writing them, and then if something already exists, that we document that so that it's easy to find later (perhaps add a comment that someone can grep for, for example). On Fri, May 21, 2021 at 9:31 AM tonygermano ***@***.***> wrote: > why not ecmaGet? I think that makes it clear what the intended purpose is. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#903 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAD7I25FIXZYGGROR2R5PHTTO2DHLANCNFSM45IXEO5A > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#903 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGADHIJBJCA6TDRX25O2V3TO2FFHANCNFSM45IXEO5A> .

[tonygermano]

The interface for ScriptableObject is Scriptable. I think I see what you are getting at. I've been wondering how to best apply internal methods and internal slots to objects because that starts to come into play when implementing ES6 inheritance. For example, you can extend the built-in Number object, and calling the super constructor causes instances of the new class to gain an internal [[NumberData]] slot.

See https://tc39.es/ecma262/#sec-number-constructor

Maybe @gbrail has some ideas since he just reworked the SlotMap classes.

[p-bakker]

The Scriptable interface doesn't cut it anymore: when looking at Proxies for example, they expect an object that conforms to the Object type as defined in the EcmaScript specification. The Scriptable interface isn't compatible.

So, I can either build Proxies against ScriptableObject directly or (try to) introduce a new interface, allowing integrators to build compatible implementations without having to extend ScriptableObject.

And secondly having an EcmaScript Object Type compatible interface would easy implementing features in a spec compliant way, as all the abstract helper methods defined in the spec could act as building blocks

[gbrail]

I usually interpret "internal data slot" as "a property on the Java class." But it depends and it can get tricky. I wrote the LambdaConstructor and LambdaFunction classes a while back to try and make the creation of new objects more JavaScript-like and less cumbersome, but we haven't actually used them to implement anything yet. That would make it easier to handle some of these "internal data slots" IMO. I recently tried to use those classes to re-implement NativeError and the result is half the size and more understandable to me at least -- I'll try and turn it into a PR soon.

…

On Fri, May 21, 2021 at 10:51 AM Paul Bakker ***@***.***> wrote: The Scriptable interface doesn't cut it anymore: when looking at Proxies for example, they expect an object that conforms to the Object type as defined in the EcmaScript specification. The Scriptable interface isn't compatible. So, I can either build Proxies against ScriptableObject directly or (try to) introduce a new interface, allowing integrators to build compatible implementations without having to extend ScriptableObject. And secondly having an EcmaScript Object Type compatible interface would easy implementing features in a spec compliant way, as all the abstract helper methods defined in the spec could act as building blocks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#903 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I26HGKCQZOCJQQKQWLTTO2MSFANCNFSM45IXEO5A> .

[p-bakker]

Closing this case, as I got my question answered. Afterwards I also realized that the Object get(Object id) methods unwraps the returned value, which isn't what should happen in the EcmaScript-defined [[Get]] operation, so the whole question was a bit mute anyway...

For the whole EcmaScriptable interface I'll open a new issue when time comes.