DefaultInternalMethod abstract operation

[annevk]

To define the Location and WindowProxy objects we need to override the default behavior for various internal methods in cross-origin scenarios and in some cases for same-origin too. However, we would still like to sometimes use the default code path defined by ECMASCript. I introduced a DefaultInternalMethod abstract operation for this, defined as follows:

DefaultInternalMethod(internalMethod, O, arguments...)

1. Return the result of calling the default ordinary object internalMethod internal method on O passing arguments as the arguments.

Invocation example: DefaultInternalMethod([[GetPrototypeOf]], O).

@domenic suggested in annevk/html-cross-origin-objects#27 to upstream this. Looking around in ECMAScript, perhaps this could be used to replace various Ordinary* abstract operations?

(See https://github.com/annevk/html-cross-origin-objects for further details. It is not yet integrated into the HTML standard, but it's getting close.)

[bterlson]

I don't think abstracting out a few words of ECMASpeak behind an abstract operation helps much on the balance, personally.

[bterlson]

I don't think abstracting out a few words of ECMASpeak behind an abstract operation helps much on the balance, personally.

[jswalden]

If it were me, I'd just make every one of the OOIMs have a one-step algorithm calling an Ordinary<name of internal method>() method defined in the same section, i.e. normalize what we've done to [[HasProperty]] to everything. Can't say I care that much how this is formatted, tho.

[jswalden]

If it were me, I'd just make every one of the OOIMs have a one-step algorithm calling an Ordinary<name of internal method>() method defined in the same section, i.e. normalize what we've done to [[HasProperty]] to everything. Can't say I care that much how this is formatted, tho.

[bterlson]

@jswalden can you give a more detailed example? Not sure I follow...

[bterlson]

@jswalden can you give a more detailed example? Not sure I follow...

[bterlson]

Also, fwiw, if we can figure out a notation to use method invocation syntax for polymorphic calls to abstract operations, it would help much here. For example, if we said we could invoke Evaluate for a particular non-terminal via _prod_::Evaluate() or |Prod|::Evaluate(), you could also imagine a dfn for OrdinaryObject combined with OrdinaryObject::[[GetPrototypeOf]](_arguments_). I would much prefer we explore this route than adding convenience abstract ops to avoid a little notational overhead for individual cases.

[bterlson]

Also, fwiw, if we can figure out a notation to use method invocation syntax for polymorphic calls to abstract operations, it would help much here. For example, if we said we could invoke Evaluate for a particular non-terminal via _prod_::Evaluate() or |Prod|::Evaluate(), you could also imagine a dfn for OrdinaryObject combined with OrdinaryObject::[[GetPrototypeOf]](_arguments_). I would much prefer we explore this route than adding convenience abstract ops to avoid a little notational overhead for individual cases.

[jswalden]

Well, we have this right now:

9.1.3 [[IsExtensible]] ( )
When the [[IsExtensible]] internal method of O is called the following steps are taken:

1. Return the value of the [[Extensible]] internal slot of O.

I'd say make it:

9.1.3 [[IsExtensible]] ( )
When the [[IsExtensible]] internal method of O is called the following steps are taken:

1. Return OrdinaryIsExtensible(O).

9.1.3.1 OrdinaryIsExtensible (O)
When the abstract operation OrdinaryIsExtensible is called with Object O, the following steps are taken:

1. Return the value of the [[Extensible]] internal slot of O.

Then it would be trivial to access the internal algorithms, no matter where used. And if they're not used, big deal -- the pattern is easily understood and should present super-minimal burden on the reader.

I will note that it's nice to have a nice name for a method like any of these, to use directly in engine API signatures. SpiderMonkey has JS::OrdinaryToPrimitive in its public API, for example, and it's easily predictable/understandable with respect to the spec because of the shared name.

[jswalden]

Well, we have this right now:

9.1.3 [[IsExtensible]] ( )
When the [[IsExtensible]] internal method of O is called the following steps are taken:

1. Return the value of the [[Extensible]] internal slot of O.

I'd say make it:

9.1.3 [[IsExtensible]] ( )
When the [[IsExtensible]] internal method of O is called the following steps are taken:

1. Return OrdinaryIsExtensible(O).

9.1.3.1 OrdinaryIsExtensible (O)
When the abstract operation OrdinaryIsExtensible is called with Object O, the following steps are taken:

1. Return the value of the [[Extensible]] internal slot of O.

Then it would be trivial to access the internal algorithms, no matter where used. And if they're not used, big deal -- the pattern is easily understood and should present super-minimal burden on the reader.

I will note that it's nice to have a nice name for a method like any of these, to use directly in engine API signatures. SpiderMonkey has JS::OrdinaryToPrimitive in its public API, for example, and it's easily predictable/understandable with respect to the spec because of the shared name.

[bterlson]

Ahh I see. That is an interesting idea...

I'm open to exploring this idea (and/or a method invocation syntax) to solve this problem generally. I don't like the DefaultInternalMethod abstract op, though, so I'll close this!

[bterlson]

Ahh I see. That is an interesting idea...

I'm open to exploring this idea (and/or a method invocation syntax) to solve this problem generally. I don't like the DefaultInternalMethod abstract op, though, so I'll close this!

[annevk]

I'm happy to see this addressed one way or another, but not having it addressed seems problematic. Are you essentially saying you want me to open a new issue? @jswalden's suggestion seems good to me. I might be okay trying to make a patch for that.

[annevk]

I'm happy to see this addressed one way or another, but not having it addressed seems problematic. Are you essentially saying you want me to open a new issue? @jswalden's suggestion seems good to me. I might be okay trying to make a patch for that.