Editorial: Add missing has operation to property operations

[bmeck]

This adds direct language about "does not have an own property with key".
This was brought up due to legacy WebIDL usage of this language from
host behavior when implementing their own exotic objects. This has been
in use for years and cannot be removed and should not be changed, this
is just explicitly adding it to the list of operations.

The spec already requires this operation be done by implementations due
to language like "... does not have an own property with key ..."

---

We might also want to note that hosts should not be using these operations in ways that break the meta object protocol. The whatwg/webidl#601 PR might better explain and show how it is being used in the MOP for WebIDL that brought this up.

[annevk]

cc @Ms2ger

[zenparsing]

Thanks @bmeck!

I've removed the Bug and Normative labels, as I think this is an editorial change: currently the meaning of "has" is implied by the description of objects as "logically a collection of properties". I'm undecided on the particular change here, but will provide feedback early next week.

[allenwb]

The purpose of the replaced text is not to define all of the MOP level operations that involve properties. That would be a much longer list than just get, set, and has.

The sentence

There are two kinds of access for properties: get and set, corresponding to value retrieval and assignment, respectively.

(subject to various tweaks) traces all the way back to ES1 but has moved around a bit. There were substantial refactoring of this section in both ES5 and ES6 but the sentence lived on. The current purpose of that paragraph is more about defining the terms own and inherited and the nature of property keys. I'd suggest replacing the above sentence with something like:

Object properties are defined and accessed via the Object Internal Methods whose semantics are defined in 6.1.7.2.

Then the following sentence:

The properties accessible via get and set access includes both own properties that are a direct part of an object and inherited properties which are provided by another associated object via a property inheritance relationship.

could be updated something like:

Various Object Internal Methods operate upon own properties that are a direct part of an object and inherited properties which are provided by another associated object via a property inheritance relationship.

[annevk]

@allenwb so you don't think property inspection and manipulation needs to be defined in detail? Or, in other words, a host environment defining an exotic object should simply aim to mimic the language used in ECMAScript to define exotic objects and not use some kind of prose-based-API?

[allenwb]

@annevk It's the job of 6.1.7.3 and 6.1.7.4 to define the generic operation that manipulate objects properties. 9.1 defines the behavior of those operations for ordinary objects. The operations for exotic objects are typically minor variation of the ordinary object operations. But in the extreme they can do any thing that is consistent with the invariants in 6.1.7.4.

a host environment defining an exotic object should simply aim to mimic the language used in ECMAScript to define exotic objects and not use some kind of prose-based-API?

I don't really understand what you are saying. Exotic objects need to be defined in terms of the operations in 6.1.7.3. You might use propose in an end user description but probably not in a specification. The subsections of 9.4 are all examples of specifying exotic objects.

[bmeck]

@allenwb I think that was the original intent of the PR linked from WebIDL but it encountered a recursion problem:

Unfortunately, I think this is an infinite recursion.

Consider a call to [[GetOwnProperty]] as defined in https://heycam.github.io/webidl/#legacy-platform-object-getownproperty. This calls https://heycam.github.io/webidl/#LegacyPlatformObjectGetOwnProperty which calls into https://heycam.github.io/webidl/#dfn-named-property-visibility for O. The proposed change would then call https://tc39.github.io/ecma262/#sec-hasownproperty on O, which will call right back into O's [[GetOwnProperty]].

What you probably need to do instead is invoke https://tc39.github.io/ecma262/#sec-ordinarygetownproperty directly or something. But note that this uses exactly the same vague "has an own property" (or rather "does not have an own property") language that webidl already has...

[annevk]

I'll try to restate it; we have an object for which one of its overridden internal methods has a step similar to

If O does not have an own property with key P

This confused folks as "have" wasn't really defined or linked and they thought it should use some kind of abstract operation instead since it wasn't the ECMAScript specification. However, using a pre-existing abstract operation would end up doing more steps, some potentially not desired.

Perhaps we should have told this person that their question was incorrect, but it wasn't quite clear to me at least that it was.

[allenwb]

What you probably need to do instead is invoke https://tc39.github.io/ecma262/#sec-ordinarygetownproperty directly or something. But note that this uses exactly the same vague "has an own property" (or rather "does not have an own property") language that webidl already has...

Yes, part of the problem is that "own property" is not formally defined anywhere and is really a concept of ordinary objects. A more formal definition of "own property" as used in 6.1.7.3 and 6.1.7.4 would essentially be "An own property of an object is a property whose property descriptor is accessible using [[GetOwnObject]]."

The whole paragraph in 6.7.1 that @bmeck was trying to tweak should probably move into 9.1 as it is describing the semantics of own and inherited objects of ordinary objects. But that is probably not enough to deal with the WebIDL issue.

Instead, it is probably the case that the meaning of own object for ordinary objects should be more concretely specified in 9.1. This is something I had toyed with several times in the past, but decided at the time that the added spec. complexity was unnecessary. What I considered doing was adding an additional internal slot called [[OwnProperties]] to each ordinary object. The value of [[OwnProperties]] would be an ordered list of key/value pairs where the key would the property key and the value was a fully complete property descriptor. The ordinary object MOP operations that add, retrieve, or otherwise manipulate "own properties" would be restated to operate upon the [[OwnProperties]] list. It would probably make sense to do so via OrdinaryXXX internal operations that could be referenced from the definitions of exotic objects.

[jmdyck]

See also issue #1067.

[annevk]

Thanks @allenwb, I think that matches the intuition I and others have about this not being as precisely defined as we'd like. I think for now IDL should keep using similar language to ECMAScript, but if this were more formally defined at some point IDL (and HTML) would definitely follow.