Re: Are internal data properties ever inherited?
Le 8 oct. 2013 à 07:21, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : On Oct 7, 2013, at 8:05 PM, Nathan Wall wrote: 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? 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) [1]; * 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. —Claude [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-property-attributes [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-internal-methods-and-internal-data-properties [3] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Are internal data properties ever inherited?
Allen Wirfs-Brock wrote: Nathan Wall wrote: 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? 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. Thanks! Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are internal data properties ever inherited?
On Oct 8, 2013, at 6:36 AM, Nathan Wall wrote: Allen Wirfs-Brock wrote: Nathan Wall wrote: 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? 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? 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: http://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: + 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]]. The above are all references to Record fields, not to internal data properties. 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. 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 http://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.; Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Are internal data properties ever inherited?
Allen Wirfs-Brock wrote: Internal implies this is not an property.; Allen Ok, thanks for clearing that up! Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are internal data properties ever inherited?
On Oct 8, 2013, at 10:38 AM, Brendan Eich wrote: 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). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are internal data properties ever inherited?
I could go with internal slot. Is data necessary? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are internal data properties ever inherited?
On Oct 8, 2013, at 11:09 AM, Brendan Eich wrote: 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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm I'm glad the alphabet is now defined (and that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm I'm glad the alphabet is now defined (and that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On 8 Oct 2013, at 19:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens math...@qiwi.be wrote: On 8 Oct 2013, at 19:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week. The document was written in July, which was before last week. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On 08/10/2013, at 19:59, Allen Wirfs-Brock wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm It provides the normative specification of the syntax of JSON Text used for data interchange. Note that it does not define any semantics for such texts. There are many such possible semantics. Actual data interchange requires agreement between a producer and consumer regarding the semantic interpretation of a JSON text. This might, for example, take the form of ad hoc agreement between a producer and consumer upon an application specific JSON schema or it might be the subject of other standards that defines a semantics for some particular use case of the Ecma-404 JSON syntax. IIUC top level values are valid JSON texts now, is that right? 4 JSON Text A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. The document is sublime. 14 pages of which 8 are not content. Now that's concise. I love it. The intro is, well, chapeau!. Thank you, -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On 8 Oct 2013, at 22:19, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens math...@qiwi.be wrote: As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week. The document was written in July, which was before last week. No need to get snarky. Why not just refer to http://www.unicode.org/versions/latest/, i.e. the latest available Unicode version? The version number doesn’t really matter for JSON as all it cares about is the concept of “code points”, the range of which is fixed. Sorry for not raising this earlier, I must’ve missed the call for feedback in/before July. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Are there any plans to introduce Date/Time literals?
Quite often Date values are used in data exchanges in form of JS
literals or JSON.
It would be beneficial if JS (and JSON as derivative) will have an
ability to represent dates literally . For example:
{
eventType: meeting,
eventStarts: 2014-11-05T13:15:30Z,
eventDurationHours: 4
}
Technically we can allow date/time format using ISO 8601 as it is.
That will require some additional look-ahead in tokenizer but is
doable as far as I can tell.
There are other options of course. Just wanted to know if this makes
sense in principle.
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Are there any plans to introduce Date/Time literals?
2013/10/8 Andrew Fedoniouk n...@terrainformatica.com:
Quite often Date values are used in data exchanges in form of JS
literals or JSON.
It would be beneficial if JS (and JSON as derivative) will have an
ability to represent dates literally . For example:
JSON can't change since it's not versioned.
http://www.json.org/fatfree.html says
JSON has no version number. No revisions to the JSON grammar are
anticipated. If something has a 1.0, it will inevitably get a 1.1 and
a 2.0, and everything is crap until it is 3.0. JSON is very stable.
{
eventType: meeting,
eventStarts: 2014-11-05T13:15:30Z,
eventDurationHours: 4
}
Technically we can allow date/time format using ISO 8601 as it is.
That will require some additional look-ahead in tokenizer but is
doable as far as I can tell.
Since JSON won't change, I don't see that this has much benefit over a
function that does the right thing w.r.t. month ordinal numbers.
Even if you could change JSON, ISO 8601 allows dropping seconds and
timezones which means you have to trade-off simplicity vs ease-of-use
to avoid ambiguity.
Consider the expression
myDate1 = 2014-11-05T13:14
myDate2 = condition1?condition2?2014-11-05T13:14:30 ...
To resolve ambiguity for date-times within deeply nested ternary
operators, you'd have to do backtracking, which you shouldn't do in
the lexer, so you have to be greedy which now means that date literals
are ok some places and not others.
Taking punctuation tokens and making them part of larger tokens
already happens in regular expression literals, and it is the source
of a lot of complexity.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On 8 Oct 2013, at 23:39, Mark S. Miller erig...@google.com wrote: JSON must not change. If it refers to the latest Unicode, whatever that is, then it is potentially subject to disruption by (admittedly unlikely) future changes to Unicode. By that logic, it should have referred to either Unicode v5.0.0 or v4.1.0 because that were the latest available versions back in July 2006 as per http://www.unicode.org/history/publicationdates.html. On 8 Oct 2013, at 23:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote: If you look at the actual dependencies, it hardly matter as they are upon things that is very hard to image ever changing. The dependencies are: 1)The definition of code point http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf#G2212 2) the actual code point to abstract character associations for the ASCII characters mentioned in the spec. 3) the UTF-16 encoding algorithm used for non-BMP code points 4) ?? is there anything else? Not as far as I can tell. On 8 Oct 2013, at 23:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I suspect the version specificity could be removed in the future. Yay! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
