Are internal data properties ever inherited?
How would you name the internal property?
If there's a symbol name, then use that, and yes: inherited just as for string-equated property names.
If truly internal, then there's no way to write what you wrote above with double-square-brackets.
I mean as far as spec semantics go.
I'm pretty sure the answer is "no", but just wanted to double check and make sure that these properties can never be inherited under any situations.
For instance, in the section for Object.prototype.toString (ES6 draft), steps 9-13 check to see if "O has a [[X]] property", where "X" is some internal data property. Based on my experience with Object.prototype.toString, I know that "has a" here really must mean "has an own"... or, put another way, the internal data properties seem to not inherit (so the word "own" isn't necessary).
From this observation, I have concluded internal data properties aren't inherited when the phrase "has a" is used... It seems to me that the obvious conclusion would be that they are never inherited under any situation, no matter the terminology used -- that internal data properties are only ever own properties. I was asking for either confirmation or to be corrected.
On Oct 7, 2013, at 8:05 PM, Nathan Wall wrote:
This should be a quick answer; I'm just looking for clarity. Are there any situations where internal data properties may be inherited? For example:
No never. "Internal data properties" are really properties at all. They are really private data fields that defined by the specification. There is no ES code level mechanisms for defining or accessing them.
An inherited @@create method might create the same internal data properties in a subclass instance that it also creates in a super class instances. But that isn't property inheritance.
Arguably it might be better to all them "internal data fields". The "internal property" terminology is a legacy that just hasn't been purged.
Set foo to bar.[[Baz]]Does
fooever result in a non-undefined value ifbardoesn't have an own[[Baz]]property but inherits from an object that has an internal[[Baz]]property?
I couldn't say, as this notation is never used in the ES specification. Hence it means whatever the person who wrote it wants it to mean.
On Oct 7, 2013, at 9:56 PM, Nathan Wall wrote: ...
For instance, in the section for Object.prototype.toString (ES6 draft), steps 9-13 check to see if "O has a [[X]] property", where "X" is some internal data property. Based on my experience with Object.prototype.toString, I know that "has a" here really must mean "has an own"... or, put another way, the internal data properties seem to not inherit (so the word "own" isn't necessary).
Actually, the say "if O has a [[X]] internal data property". If you ever see "a [[x]] property", that's an editorial bug. Please report it.
From this observation, I have concluded internal data properties aren't inherited when the phrase "has a" is used... It seems to me that the obvious conclusion would be that they are never inherited under any situation, no matter the terminology used -- that internal data properties are only ever own properties. I was asking for either confirmation or to be corrected.
The definition of "internal data property" is in people.mozilla.org/~jorendorff/es6-draft.html#sec-6.1.7.2
Le 8 oct. 2013 à 07:21, Allen Wirfs-Brock <allen at wirfs-brock.com> a écrit :
On Oct 7, 2013, at 8:05 PM, Nathan Wall wrote:
Set foo to bar.[[Baz]]Does
fooever result in a non-undefined value ifbardoesn't have an own[[Baz]]property but inherits from an object that has an internal[[Baz]]property?I couldn't say, as this notation is never used in the ES specification. Hence it means whatever the person who wrote it wants it to mean.
It may be useful to recall that there are different concepts in the spec that have a name enclosed in double square brackets. I have found these three:
- attributes of object properties (Section 6.1.7.1);
- internal methods and internal data properties of objects (Section 6.1.7.2);
- fields of records (Section 6.2.2).
Among those concepts, the notation O.[[X]] is defined (and, I presume, used) only for fields of records. But there is some risk for the reader to accidentally extend this notation to internal data properties of objects.
Allen Wirfs-Brock wrote:
Nathan Wall wrote:
Set foo to bar.[[Baz]]
Does
fooever result in a non-undefined value ifbardoesn't have an own[[Baz]]property but inherits from an object that has an internal[[Baz]]property?I couldn't say, as this notation is never used in the ES specification. Hence it means whatever the person who wrote it wants it to mean.
What do you mean?
Here are some examples where this notation is used in Rev. 19:
- 9.1.15.1 [[Call]] (thisArgument, argumentsList) + Step 9.b.i.1 Set thisValue to calleeRealm.[[globalThis]].
- 9.2.2.1 [[DefineOwnProperty]] (P, Desc) + Step 3.b Let oldLen be oldLenDesc.[[Value]].
- 16.6.2.2 Runtime Semantics: LabelEvaluation + Step 2.f ... let V = stmt.[[value]]
- 14.1.13 Runtime Semantics: IndexedBindingInitialisation + FunctionRestParameter : ... BindingIdentifier + Step 3 Let argumentsLength be status.[[value]].
There acutlly appears to be only one occurance of "Set ... to ...". Other occurrences say "Let ... be ...", so I should have used that terminology. Apologies.
I think I have my answer, though. Internal implies own.
On Oct 8, 2013, at 6:36 AM, Nathan Wall wrote:
What do you mean?
Sorry, I should have been clearer. The dot notation is never used in the spec to refer to internal data properties.
As Claude pointed out, it is used to refer to the fields of the record specification type: people.mozilla.org/~jorendorff/es6-draft.html#sec-6.2.2
Records are an abstract data structure used in the specification. The do not correspond to ES Objects. Their fields are neither object properties or internal data properties.
Here are some examples where this notation is used in Rev. 19:
The above are all references to Record fields, not to internal data properties.
I think I have my answer, though. Internal implies own.
Yes and no! That's really the wrong way to think about it. Internal data properties are not object properties. The definition of properties in people.mozilla.org/~jorendorff/es6-draft.html#sec-6.1.7 does not apply to them. The concepts of own and inherited as defined in that section does not apply to them. They are basically private per object state. You will be on the road to confusion if you think about them as simply a specialization of ECMAScript object properties.
"Internal" implies "this is not an property".
The phrase needs to drop the p-word, then -- post haste!
Allen Wirfs-Brock wrote:
"Internal" implies "this is not an property".
Ok, thanks for clearing that up!
Claude Pache wrote:
It may be useful to recall that there are different concepts in the spec that have a name enclosed in double square brackets. I have found these three:
- attributes of object properties (Section 6.1.7.1) [1];
Note this is an ES5 change from ES1-3, which used DontDelete, DontEnum, and ReadOnly without [[]] brackets.
- internal methods and internal data properties of objects (Section 6.1.7.2) [2];
- fields of records (Section 6.2.2) [3].
Among those concepts, the notation
O.[[X]]is defined (and, I presume, used) only for fields of records. But there is some risk for the reader to accidentally extend this notation to internal data properties of objects.
I agree on risk of confusion. Distinct notation for notably distinct spec constructs seems best. Just [[]]-bracketing all spec-level or unreflected meta-level names does not achieve any particular goal, and we don't do that anyway.
In contrast to programming languages hindered by QWERTY and ASCII legacies, the Spec has lots of typographic expressiveness to choose from. True, ASCII transcriptions and mockups would be harder, but some alternative brackets (chevrons) have digraphs (<< and >>). And perhaps
just a few nice font choices and no brackets (which add non-trivial visual noise) would be better for some use-cases.
Allen, what do you think?
I generally agree but, I'm also much more focused right now on getting the ES6 spec. feature complete than I am on notational cleanups.
For now, I think it is probably adequate to clarify that [[ ]] is always used to designate meta-level specification names. There has also been enough confusion about the differences between meta-level "internal data properties" and ECMAScript language "data properties" to justify a global renaming of "internal data property" to "internal data field" (or perhaps "internal data slot", I'm concern about possible confusion with "fields" of the Record specification type).
I could go with "internal slot". Is "data" necessary?
or perhaps just "slot".
One concern with inventing terminology at this time is that we really don't know how we will want to talk about language level private object state assuming when it gets introduced post ES6.
Yes, I agree -- but we have relationships and fields, and I am willing to foreswear using "slot" at language level in the future :-).
This should be a quick answer; I'm just looking for clarity. Are there any situations where internal data properties may be inherited? For example:
Does
fooever result in a non-undefined value ifbardoesn't have an own[[Baz]]property but inherits from an object that has an internal[[Baz]]property?This should be a quick answer; I'm just looking for clarity. Are there any situations where internal data properties may be inherited? For example: Set foo to bar.[[Baz]] Does `foo` ever result in a non-undefined value if `bar` doesn't have an own `[[Baz]]` property but inherits from an object that has an internal `[[Baz]]` property? Thanks,Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131007/c4756b74/attachment.html>