Ordinary* methods inconsistent in invoking [[*]] vs Ordinary* in their steps

[annevk]

OrdinaryHasProperty invokes OrdinaryGetOwnProperty directly, not [[GetOwnProperty]].

The other Ordinary* methods we introduced invoke [[*]] rather than Ordinary* in their algorithms. The former is more useful for reuse by the WindowProxy and Location exotic objects, but I can imagine the latter being important for some cases too. Is there a reason OrdinaryHasProperty behaves the way it does?

Even if OrdinaryHasProperty remains the way it is, can I be sure that we will not change OrdinaryGet et al from invoking [[*]] to invoking Ordinary*?

[anba]

It seems to be doable to replace OrdinaryGetOwnProperty with [[GetOwnProperty]] in OrdinaryHasProperty. The internal methods for String and Arguments objects only require two simple changes:

1. String objects

   • [[HasProperty]] can be removed
   • StringGetIndexProperty can be inlined into [[GetOwnProperty]]

2. Arguments objects

   • [[HasProperty]] needs to be added to avoid throwing a TypeError for "caller" in arguments (when the legacy caller property is supported)

   [[HasProperty]](P)
   
   1. Let _args_ be the arguments object.
   1. If _P_ is `"caller"`, then
      1. Let _desc_ be OrdinaryGetOwnProperty(_args_, _P_).
      1. If IsDataDescriptor(_desc_) is *true*, return *true*.
   1. Return OrdinaryHasProperty(_args_, _P_).
   
   NOTE: If an implementation does not provide a built-in caller property for argument exotic objects then step 2 of this algorithm must be skipped.

[anba]

It seems to be doable to replace OrdinaryGetOwnProperty with [[GetOwnProperty]] in OrdinaryHasProperty. The internal methods for String and Arguments objects only require two simple changes:

1. String objects

   • [[HasProperty]] can be removed
   • StringGetIndexProperty can be inlined into [[GetOwnProperty]]

2. Arguments objects

   • [[HasProperty]] needs to be added to avoid throwing a TypeError for "caller" in arguments (when the legacy caller property is supported)

   [[HasProperty]](P)
   
   1. Let _args_ be the arguments object.
   1. If _P_ is `"caller"`, then
      1. Let _desc_ be OrdinaryGetOwnProperty(_args_, _P_).
      1. If IsDataDescriptor(_desc_) is *true*, return *true*.
   1. Return OrdinaryHasProperty(_args_, _P_).
   
   NOTE: If an implementation does not provide a built-in caller property for argument exotic objects then step 2 of this algorithm must be skipped.

[annevk]

Thank you @anba. @bterlson does that seem acceptable? If we go this way, should we state somewhere that this is an invariant of internal methods? That the internal algorithms of ordinary internal methods always invoke internal methods directly (and not the internal algorithms).

[annevk]

Thank you @anba. @bterlson does that seem acceptable? If we go this way, should we state somewhere that this is an invariant of internal methods? That the internal algorithms of ordinary internal methods always invoke internal methods directly (and not the internal algorithms).

[bterlson]

The change suggested by @anba seems fine.

I'm not sure this is an invariant per se - I could still imagine calling an ordinary object method's abstract operation directly at some point if needed. But since we wouldn't at all after this change, I would be ok including this as a note of sorts in 9.1, stating something like:

Each ordinary object internal method delegates to a similarly-named abstract operation. If such an abstract operation depends on another internal method, then the internal method it is invoked by referencing the slot on O rather than calling the abstract operation directly. This semantics ensures that exotic objects have their overridden internal methods invoked when ordinary object internal methods are applied to them.

[bterlson]

The change suggested by @anba seems fine.

I'm not sure this is an invariant per se - I could still imagine calling an ordinary object method's abstract operation directly at some point if needed. But since we wouldn't at all after this change, I would be ok including this as a note of sorts in 9.1, stating something like:

Each ordinary object internal method delegates to a similarly-named abstract operation. If such an abstract operation depends on another internal method, then the internal method it is invoked by referencing the slot on O rather than calling the abstract operation directly. This semantics ensures that exotic objects have their overridden internal methods invoked when ordinary object internal methods are applied to them.