Re: thoughts the (re)organization of the specification?

[David Herman]

It's always fun to think of ways to make a better spec. But also good to keep 
in mind the risks:

- The spec is not in any machine-readable form, meaning it's neither testable 
nor formally verifiable in any way. This means refactoring must be done 
carefully, since it can't be verified.

- The more radical the changes, the more risk of introducing bugs, ranging from 
minor to deep/logical. Even minor bugs risk interoperability problems as 
implementers diverge in interpretation.

- Major rejiggering of the spec could result in difficulties in tracking 
implementation conformance, as implementations are often written to follow the 
spec structure, and often have inline comments referencing their corresponding 
ES3/5 semantic steps. But I chatted with Jason Orendorff and he wasn't too 
concerned about Allen's suggestions.

- The more radical the changes, the more editorial work it takes. We're on a 
schedule, we can't fork Allen, and anyway it'd probably be hard to have 
multiple authors doing serious concurrent work within Word.

That said, Allen's the best judge of what organizational changes he thinks need 
to be made and what he can reasonably accomplish within our time frame. I love 
the changes Allen made in ES5 (e.g. the declarative environment frames), and 
I'm happy to see evolutionary improvements to the structure of the spec.

Dave

On Nov 2, 2012, at 9:55 PM, Axel Rauschmayer  wrote:

>> Have you considered to split this spec into two part: one is for language 
>> implementer and the other is for language user?
> 
> Interesting idea! You could argue that writing the second part is the job of 
> JavaScript book authors.
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> ___
> 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: thoughts the (re)organization of the specification?

[Axel Rauschmayer]

> Have you considered to split this spec into two part: one is for language 
> implementer and the other is for language user?


Interesting idea! You could argue that writing the second part is the job of 
JavaScript book authors.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: thoughts the (re)organization of the specification?

[程劭非]

Looks good.

Have you considered to split this spec into two part: one is for language
implementer and the other is for language user?



2012/11/3 Allen Wirfs-Brock 

> In both ES5 and ES6 (so far) we have generally tried to maintain the
> section structure of the previous editions.  Occasionally we have had to do
> some minor subsection renumbering (or not so minor in the case of ES5
> section 10) but have generally maintained the overall structure of the
> entire document, even when it has appeared to non-optimial or even
> confusing.
>
> I'm now looking at the work to implement the refactoring of the  internal
> methods in section 8 and I see we are probably going to loose even more of
> the section number correspondence with previous editions.  This tempts me
> to seize the moment, abandon the legacy organization, and reorganize in a
> more logical manner.
>
> Here is the new structure that I have in mind, with reference to existing
> ES5 (section numbers:)
>
> Introductory Material
> Scope (1)
> Conformance (2)
> Normative References (3)
> Overview (4)
> Notational Conventions(5)
>
> The ECMAScript Computational Engine
> Data Types and Values (8)
> Commonly used Abstract Operations (9)
> ECMAScript Execution (10 and possibly parts of 14)
> [Possibly new material related to module loaders and realms]
>
> The ECMAScript Programming Language
> Source Text (6)
> Conformance, Error Handling, and Extensions (16)
> Lexical Tokens (7)
> Expressions  (11)
> Statements (12)
> Functions and Classes (13)
> Scripts and Modules (14)
>
> The ECMAScript Standard Library (15)
>  [potentially some reordering and reorganization]
>
> Annexes
>
>
> What thoughts do people have  about this? Should we go for an improved
> document organization or should be continue to patch around the current
> structure, probably forever.  If we do restructure, I would probably do
> most of the work after we were feature complete and until them, only make
> incremental changes that make sense that the context of new feature work.
> But it would be helpful to decide soon which path we are going to take.
>
> One of the issue is the correspondence between the spec. organization and
> the test262 organization.  We already have massive changes changes and the
> algorithm and algorithm set level that will impact test232, so I'm not sure
> that the higher level reorg that I'm thinking about would have that much
> more impact on it.
>
> Feedback???
>
> 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: thoughts the (re)organization of the specification?

[Norbert Lindenberg]

On Nov 2, 2012, at 23:08 , Allen Wirfs-Brock wrote:

> I'm now looking at the work to implement the refactoring of the  internal 
> methods in section 8 and I see we are probably going to loose even more of 
> the section number correspondence with previous editions.  This tempts me to 
> seize the moment, abandon the legacy organization, and reorganize in a more 
> logical manner.

Yes, please.

> The ECMAScript Standard Library (15)
> [potentially some reordering and reorganization]

I'd suggest:

- Break it up into separate chapters for each of the current second-level 
sections, plus one for general requirements for all standard built-ins (the 
currently unnumbered introduction). Given the size of the ES6 spec, we may want 
to produce a multi-part HTML version and/or an ePub version for tablets, and 
for both a single chapter containing half the spec would be hard to digest.

- Reorganize the method lists from sediment layers back into some logical 
structure.

Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: thoughts the (re)organization of the specification?

[Axel Rauschmayer]

+1

I'm not sure that there would be enough content, but you could have a part 
titled “Grammar”.


[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com

On 02.11.2012, at 23:08, Allen Wirfs-Brock  wrote:

> In both ES5 and ES6 (so far) we have generally tried to maintain the section 
> structure of the previous editions.  Occasionally we have had to do some 
> minor subsection renumbering (or not so minor in the case of ES5 section 10) 
> but have generally maintained the overall structure of the entire document, 
> even when it has appeared to non-optimial or even confusing. 
> 
> I'm now looking at the work to implement the refactoring of the  internal 
> methods in section 8 and I see we are probably going to loose even more of 
> the section number correspondence with previous editions.  This tempts me to 
> seize the moment, abandon the legacy organization, and reorganize in a more 
> logical manner.
> 
> Here is the new structure that I have in mind, with reference to existing ES5 
> (section numbers:)
> 
> Introductory Material
>Scope (1)
>Conformance (2)
>Normative References (3)
>Overview (4)
>Notational Conventions(5)
> 
> The ECMAScript Computational Engine
>Data Types and Values (8)
>Commonly used Abstract Operations (9)
>ECMAScript Execution (10 and possibly parts of 14)
>[Possibly new material related to module loaders and realms] 
> 
> The ECMAScript Programming Language
>Source Text (6)
>Conformance, Error Handling, and Extensions (16)
>Lexical Tokens (7)
>Expressions  (11)
>Statements (12)
>Functions and Classes (13)
>Scripts and Modules (14)
> 
> The ECMAScript Standard Library (15)
> [potentially some reordering and reorganization]
> 
> Annexes
> 
> 
> What thoughts do people have  about this? Should we go for an improved 
> document organization or should be continue to patch around the current 
> structure, probably forever.  If we do restructure, I would probably do most 
> of the work after we were feature complete and until them, only make 
> incremental changes that make sense that the context of new feature work. But 
> it would be helpful to decide soon which path we are going to take.
> 
> One of the issue is the correspondence between the spec. organization and the 
> test262 organization.  We already have massive changes changes and the 
> algorithm and algorithm set level that will impact test232, so I'm not sure 
> that the higher level reorg that I'm thinking about would have that much more 
> impact on it.
> 
> Feedback???
> 
> 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: thoughts the (re)organization of the specification?

[Yehuda Katz]

Same here. Carpe diem.

-- Yehuda Katz
(ph) 718.877.1325
On Nov 2, 2012 7:24 PM, "Kevin Smith"  wrote:

> Just speaking as a spec reader, I say go for it.
>
> - Kevin
>
>
> On Fri, Nov 2, 2012 at 6:08 PM, Allen Wirfs-Brock 
> wrote:
>
>> In both ES5 and ES6 (so far) we have generally tried to maintain the
>> section structure of the previous editions.  Occasionally we have had to do
>> some minor subsection renumbering (or not so minor in the case of ES5
>> section 10) but have generally maintained the overall structure of the
>> entire document, even when it has appeared to non-optimial or even
>> confusing.
>>
>> I'm now looking at the work to implement the refactoring of the  internal
>> methods in section 8 and I see we are probably going to loose even more of
>> the section number correspondence with previous editions.  This tempts me
>> to seize the moment, abandon the legacy organization, and reorganize in a
>> more logical manner.
>>
>> Here is the new structure that I have in mind, with reference to existing
>> ES5 (section numbers:)
>>
>> Introductory Material
>> Scope (1)
>> Conformance (2)
>> Normative References (3)
>> Overview (4)
>> Notational Conventions(5)
>>
>> The ECMAScript Computational Engine
>> Data Types and Values (8)
>> Commonly used Abstract Operations (9)
>> ECMAScript Execution (10 and possibly parts of 14)
>> [Possibly new material related to module loaders and realms]
>>
>> The ECMAScript Programming Language
>> Source Text (6)
>> Conformance, Error Handling, and Extensions (16)
>> Lexical Tokens (7)
>> Expressions  (11)
>> Statements (12)
>> Functions and Classes (13)
>> Scripts and Modules (14)
>>
>> The ECMAScript Standard Library (15)
>>  [potentially some reordering and reorganization]
>>
>> Annexes
>>
>>
>> What thoughts do people have  about this? Should we go for an improved
>> document organization or should be continue to patch around the current
>> structure, probably forever.  If we do restructure, I would probably do
>> most of the work after we were feature complete and until them, only make
>> incremental changes that make sense that the context of new feature work.
>> But it would be helpful to decide soon which path we are going to take.
>>
>> One of the issue is the correspondence between the spec. organization and
>> the test262 organization.  We already have massive changes changes and the
>> algorithm and algorithm set level that will impact test232, so I'm not sure
>> that the higher level reorg that I'm thinking about would have that much
>> more impact on it.
>>
>> Feedback???
>>
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Axel Rauschmayer]

+1

I have always found Java’s collection API fairly intuitive. It could serve as a 
role model, at least partially.
- Map: containsKey, containsValue
- Set: contains

Note that it has an isEmpty() method. I would also want to have its methods for 
combining collections such as removeAll() and retainAll().

http://docs.oracle.com/javase/6/docs/api/java/util/Map.html
http://docs.oracle.com/javase/6/docs/api/java/util/Set.html


[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com

On 02.11.2012, at 22:30, Allen Wirfs-Brock  wrote:

> 
> On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:
> 
>> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola 
>>  wrote:
>>> > If we call it "has", should we also rename String.prototype.contains?
>>> 
>>> I'd say no; the distinction between collections "having" an element and 
>>> strings "containing" a substring seems very sensible. It's a bit more 
>>> awkward to say a string "has" a substring, and a string is definitely not a 
>>> collection of substrings in any reasonable sense.
>> 
>> Well, you could also note that array.has(x) looks for a particular value, 
>> while map.has(x) looks for a particular key.
>> 
>> But that's not the point. There's no common formal contract implemented by 
>> all these methods; what they share is an informal "hey, look in this thing, 
>> and tell me if you see that thing" vibe.
> 
> There is no verifiable formal contract.  But there can be an informal 
> contract.  In my experience, it is very important when using a dynamic 
> language to recognize and try to support such informal contracts. 
> 
> All the uses of "has" we have defined so far are about the "keys".  Having 
> one place that is about the "values" to create unnecessary confusion
> 
> Note that we (the JS/ES designers) already have a history of being being 
> inconsistent in our use of names.  Consider String indexOf and Array indexOf 
> they are named the same and appear to have signatures.  But they logically 
> are doing quite different things.  String indexOf is looking for the index of 
> the first element of a subsequence of character elements that matches a 
> specific character sequence.  Array indexOf is looking for the index of a 
> single element that contains a specific value.  You might want to implement a 
> logically similar subsequence search for Array's but if you do, you can't 
> call it indexOf because that name was already used for something with 
> different semantics.  We should try to do better as people for our example.
> 
> 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: thoughts the (re)organization of the specification?

[Kevin Smith]

Just speaking as a spec reader, I say go for it.

- Kevin


On Fri, Nov 2, 2012 at 6:08 PM, Allen Wirfs-Brock wrote:

> In both ES5 and ES6 (so far) we have generally tried to maintain the
> section structure of the previous editions.  Occasionally we have had to do
> some minor subsection renumbering (or not so minor in the case of ES5
> section 10) but have generally maintained the overall structure of the
> entire document, even when it has appeared to non-optimial or even
> confusing.
>
> I'm now looking at the work to implement the refactoring of the  internal
> methods in section 8 and I see we are probably going to loose even more of
> the section number correspondence with previous editions.  This tempts me
> to seize the moment, abandon the legacy organization, and reorganize in a
> more logical manner.
>
> Here is the new structure that I have in mind, with reference to existing
> ES5 (section numbers:)
>
> Introductory Material
> Scope (1)
> Conformance (2)
> Normative References (3)
> Overview (4)
> Notational Conventions(5)
>
> The ECMAScript Computational Engine
> Data Types and Values (8)
> Commonly used Abstract Operations (9)
> ECMAScript Execution (10 and possibly parts of 14)
> [Possibly new material related to module loaders and realms]
>
> The ECMAScript Programming Language
> Source Text (6)
> Conformance, Error Handling, and Extensions (16)
> Lexical Tokens (7)
> Expressions  (11)
> Statements (12)
> Functions and Classes (13)
> Scripts and Modules (14)
>
> The ECMAScript Standard Library (15)
>  [potentially some reordering and reorganization]
>
> Annexes
>
>
> What thoughts do people have  about this? Should we go for an improved
> document organization or should be continue to patch around the current
> structure, probably forever.  If we do restructure, I would probably do
> most of the work after we were feature complete and until them, only make
> incremental changes that make sense that the context of new feature work.
> But it would be helpful to decide soon which path we are going to take.
>
> One of the issue is the correspondence between the spec. organization and
> the test262 organization.  We already have massive changes changes and the
> algorithm and algorithm set level that will impact test232, so I'm not sure
> that the higher level reorg that I'm thinking about would have that much
> more impact on it.
>
> Feedback???
>
> 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: Array.prototype.contains

[Allen Wirfs-Brock]

On Nov 2, 2012, at 5:45 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>>> "has" for keys (and possibly values of a Set, to preserve the value mapped 
>>> to boolean future option that forEach also supports), "contains" for values 
>>> in arrays
>> 
>> sounds ok, except we get the same issue for contains that we have for 
>> indexOf.  II guess the big thing with contains is that it can be applied no 
>> non-indexed collections (maps, sets, etc.).
> 
> I'm not sure there's enough of a problem with using contains (or indexOf) to 
> justify splitting contains-names, which has its own problems (inconsistency 
> with indexOf, also with other languages, _mutatis mutandis_, e.g. Java).

me neither...just a wart




> 
>> Also any reason contains should be provided for WeakMap? I not seeing why it 
>> shouldn't be there too.
> 
> How about Map contains (as well as has)?
> 
> How about Set for that matter?

Because people might actually use Map contains not realizing it isn't a near 
constant time probe like has.  But, that concern is offset by the disability  
of having a consistent set of collection interfaces plus we don't like being a 
nannies.

I'd probably be on board with with having both for Set/Map/WeakMap


Allen 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Brendan Eich]

Allen Wirfs-Brock wrote:

"has" for keys (and possibly values of a Set, to preserve the value mapped to boolean 
future option that forEach also supports), "contains" for values in arrays


sounds ok, except we get the same issue for contains that we have for indexOf.  
II guess the big thing with contains is that it can be applied no non-indexed 
collections (maps, sets, etc.).


I'm not sure there's enough of a problem with using contains (or 
indexOf) to justify splitting contains-names, which has its own problems 
(inconsistency with indexOf, also with other languages, _mutatis 
mutandis_, e.g. Java).



Also any reason contains should be provided for WeakMap? I not seeing why it 
shouldn't be there too.


How about Map contains (as well as has)?

How about Set for that matter?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Allen Wirfs-Brock]

On Nov 2, 2012, at 4:54 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> ...
>> Note that we (the JS/ES designers) already have a history of being being 
>> inconsistent in our use of names.  Consider String indexOf and Array indexOf
> 
> http://stackoverflow.com/questions/4962361/where-is-javas-array-indexof
> 
>> they are named the same and appear to have signatures.  But they logically 
>> are doing quite different things.  String indexOf is looking for the index 
>> of the first element of a subsequence of character elements that matches a 
>> specific character sequence.  Array indexOf is looking for the index of a 
>> single element that contains a specific value.  You might want to implement 
>> a logically similar subsequence search for Array's but if you do, you can't 
>> call it indexOf because that name was already used for something with 
>> different semantics.  We should try to do better as people for our example.
> 
> That one never bugged me, and I suppose one could "fix" it by allowing 
> by-value search for a sub-array from Array.prototype.indexOf. I've never seen 
> anyone do that.

It never bothered me either up to now. Probably because we usually don't think 
about JS strings as a "collections"  (immutable array of uint16s) all that 
much.  But if you starting thinking about  strings as a kind of collection and 
look for uniformity in collection interfaces, indexOf stands out as being 
problematic. 


> 
> "has" for keys (and possibly values of a Set, to preserve the value mapped to 
> boolean future option that forEach also supports), "contains" for values in 
> arrays
> 

sounds ok, except we get the same issue for contains that we have for indexOf.  
II guess the big thing with contains is that it can be applied no non-indexed 
collections (maps, sets, etc.). 

Also any reason contains should be provided for WeakMap? I not seeing why it 
shouldn't be there too.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Brendan Eich]

Andrea Giammarchi wrote:
I actually agree on this, but Set.has() is misleading then, imho. 
Shouldn't be specified that `has()` is key related and `contains()` is 
value related?


The forEach signature has (value, key, collection), and for a Set is 
called with (value, value, theSet). We discussed this at the Boston f2f 
and recently on list. It allows us to extend Sets in the future (under 
object model reformation, e.g.) to map value to boolean has-result.


Apart from the Set special case, using contains for values and has for 
keys seems better and better to me. But that means 
String.prototype.contains, not has. The test is for values, not keys, in 
that case. Same thing with Array.prototype.contains (and MooTools must 
adapt).


/be

Also a "magic" Object.has(obj, key) with smart obj recognition and 
Object.contains(obj, value) would be probably cool



On Fri, Nov 2, 2012 at 2:30 PM, Allen Wirfs-Brock 
mailto:al...@wirfs-brock.com>> wrote:



On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:


On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola
mailto:dome...@domenicdenicola.com>> wrote:

> If we call it "has", should we also rename
String.prototype.contains?

I'd say no; the distinction between collections "having" an
element and strings "containing" a substring seems very
sensible. It's a bit more awkward to say a string "has" a
substring, and a string is definitely not a collection of
substrings in any reasonable sense.


Well, you could also note that array.has(x) looks for a
particular value, while map.has(x) looks for a particular key.

But that's not the point. There's no common formal contract
implemented by all these methods; what they share is an informal
"hey, look in this thing, and tell me if you see that thing" vibe.


There is no verifiable formal contract.  But there can be an
informal contract.  In my experience, it is very important when
using a dynamic language to recognize and try to support such
informal contracts.

All the uses of "has" we have defined so far are about the "keys".
 Having one place that is about the "values" to create unnecessary
confusion

Note that we (the JS/ES designers) already have a history of being
being inconsistent in our use of names.  Consider String indexOf
and Array indexOf they are named the same and appear to have
signatures.  But they logically are doing quite different things.
 String indexOf is looking for the index of the first element of a
subsequence of character elements that matches a specific
character sequence.  Array indexOf is looking for the index of a
single element that contains a specific value.  You might want to
implement a logically similar subsequence search for Array's but
if you do, you can't call it indexOf because that name was already
used for something with different semantics.  We should try to do
better as people for our example.

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Brendan Eich]

Allen Wirfs-Brock wrote:

On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:
On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:


> If we call it "has", should we also rename
String.prototype.contains?

I'd say no; the distinction between collections "having" an
element and strings "containing" a substring seems very sensible.
It's a bit more awkward to say a string "has" a substring, and a
string is definitely not a collection of substrings in any
reasonable sense.


Well, you could also note that array.has(x) looks for a particular 
value, while map.has(x) looks for a particular key.


But that's not the point. There's no common formal contract 
implemented by all these methods; what they share is an informal 
"hey, look in this thing, and tell me if you see that thing" vibe.


There is no verifiable formal contract.  But there can be an informal 
contract.  In my experience, it is very important when using a dynamic 
language to recognize and try to support such informal contracts.


All the uses of "has" we have defined so far are about the "keys". 
 Having one place that is about the "values" to create unnecessary 
confusion


Note that we (the JS/ES designers) already have a history of being 
being inconsistent in our use of names.  Consider String indexOf and 
Array indexOf


http://stackoverflow.com/questions/4962361/where-is-javas-array-indexof

they are named the same and appear to have signatures.  But they 
logically are doing quite different things.  String indexOf is looking 
for the index of the first element of a subsequence of character 
elements that matches a specific character sequence.  Array indexOf is 
looking for the index of a single element that contains a specific 
value.  You might want to implement a logically similar subsequence 
search for Array's but if you do, you can't call it indexOf because 
that name was already used for something with different semantics.  We 
should try to do better as people for our example.


That one never bugged me, and I suppose one could "fix" it by allowing 
by-value search for a sub-array from Array.prototype.indexOf. I've never 
seen anyone do that.


"has" for keys (and possibly values of a Set, to preserve the value 
mapped to boolean future option that forEach also supports), "contains" 
for values in arrays?


/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: thoughts the (re)organization of the specification?

[Glenn Adams]

On Fri, Nov 2, 2012 at 11:08 PM, Allen Wirfs-Brock wrote:

> I'm now looking at the work to implement the refactoring of the  internal
> methods in section 8 and I see we are probably going to loose even more of
> the section number correspondence with previous editions.  This tempts me
> to seize the moment, abandon the legacy organization, and reorganize in a
> more logical manner.
>

carpe diem
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

thoughts the (re)organization of the specification?

[Allen Wirfs-Brock]

In both ES5 and ES6 (so far) we have generally tried to maintain the section 
structure of the previous editions.  Occasionally we have had to do some minor 
subsection renumbering (or not so minor in the case of ES5 section 10) but have 
generally maintained the overall structure of the entire document, even when it 
has appeared to non-optimial or even confusing. 

I'm now looking at the work to implement the refactoring of the  internal 
methods in section 8 and I see we are probably going to loose even more of the 
section number correspondence with previous editions.  This tempts me to seize 
the moment, abandon the legacy organization, and reorganize in a more logical 
manner.

Here is the new structure that I have in mind, with reference to existing ES5 
(section numbers:)

Introductory Material
Scope (1)
Conformance (2)
Normative References (3)
Overview (4)
Notational Conventions(5)

The ECMAScript Computational Engine
Data Types and Values (8)
Commonly used Abstract Operations (9)
ECMAScript Execution (10 and possibly parts of 14)
[Possibly new material related to module loaders and realms] 

The ECMAScript Programming Language
Source Text (6)
Conformance, Error Handling, and Extensions (16)
Lexical Tokens (7)
Expressions  (11)
Statements (12)
Functions and Classes (13)
Scripts and Modules (14)

The ECMAScript Standard Library (15)
 [potentially some reordering and reorganization]

Annexes


What thoughts do people have  about this? Should we go for an improved document 
organization or should be continue to patch around the current structure, 
probably forever.  If we do restructure, I would probably do most of the work 
after we were feature complete and until them, only make incremental changes 
that make sense that the context of new feature work. But it would be helpful 
to decide soon which path we are going to take.

One of the issue is the correspondence between the spec. organization and the 
test262 organization.  We already have massive changes changes and the 
algorithm and algorithm set level that will impact test232, so I'm not sure 
that the higher level reorg that I'm thinking about would have that much more 
impact on it.

Feedback???

Allen




 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Andrea Giammarchi]

I actually agree on this, but Set.has() is misleading then, imho. Shouldn't
be specified that `has()` is key related and `contains()` is value related?
Also a "magic" Object.has(obj, key) with smart obj recognition and
Object.contains(obj, value) would be probably cool


On Fri, Nov 2, 2012 at 2:30 PM, Allen Wirfs-Brock wrote:

>
> On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:
>
> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> > If we call it "has", should we also rename String.prototype.contains?
>>
>> I'd say no; the distinction between collections "having" an element and
>> strings "containing" a substring seems very sensible. It's a bit more
>> awkward to say a string "has" a substring, and a string is definitely not a
>> collection of substrings in any reasonable sense.
>>
>
> Well, you could also note that array.has(x) looks for a particular value,
> while map.has(x) looks for a particular key.
>
> But that's not the point. There's no common formal contract implemented by
> all these methods; what they share is an informal "hey, look in this thing,
> and tell me if you see that thing" vibe.
>
>
> There is no verifiable formal contract.  But there can be an informal
> contract.  In my experience, it is very important when using a dynamic
> language to recognize and try to support such informal contracts.
>
> All the uses of "has" we have defined so far are about the "keys".  Having
> one place that is about the "values" to create unnecessary confusion
>
> Note that we (the JS/ES designers) already have a history of being being
> inconsistent in our use of names.  Consider String indexOf and Array
> indexOf they are named the same and appear to have signatures.  But they
> logically are doing quite different things.  String indexOf is looking for
> the index of the first element of a subsequence of character elements that
> matches a specific character sequence.  Array indexOf is looking for the
> index of a single element that contains a specific value.  You might want
> to implement a logically similar subsequence search for Array's but if you
> do, you can't call it indexOf because that name was already used for
> something with different semantics.  We should try to do better as people
> for our example.
>
> 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: Array.prototype.contains

[Allen Wirfs-Brock]

On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:

> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola 
>  wrote:
> > If we call it "has", should we also rename String.prototype.contains?
> 
> I'd say no; the distinction between collections "having" an element and 
> strings "containing" a substring seems very sensible. It's a bit more awkward 
> to say a string "has" a substring, and a string is definitely not a 
> collection of substrings in any reasonable sense.
> 
> Well, you could also note that array.has(x) looks for a particular value, 
> while map.has(x) looks for a particular key.
> 
> But that's not the point. There's no common formal contract implemented by 
> all these methods; what they share is an informal "hey, look in this thing, 
> and tell me if you see that thing" vibe.

There is no verifiable formal contract.  But there can be an informal contract. 
 In my experience, it is very important when using a dynamic language to 
recognize and try to support such informal contracts. 

All the uses of "has" we have defined so far are about the "keys".  Having one 
place that is about the "values" to create unnecessary confusion

Note that we (the JS/ES designers) already have a history of being being 
inconsistent in our use of names.  Consider String indexOf and Array indexOf 
they are named the same and appear to have signatures.  But they logically are 
doing quite different things.  String indexOf is looking for the index of the 
first element of a subsequence of character elements that matches a specific 
character sequence.  Array indexOf is looking for the index of a single element 
that contains a specific value.  You might want to implement a logically 
similar subsequence search for Array's but if you do, you can't call it indexOf 
because that name was already used for something with different semantics.  We 
should try to do better as people for our example.

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Andrea Giammarchi]

fair enough, but I want to know what I am seeing is recorded and the TV is
switched off ... how? Flagging records? Flagging objects? Via getNotifier ?


On Fri, Nov 2, 2012 at 11:56 AM, Erik Arvidsson wrote:

> On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi
>  wrote:
> > How to make this simple ... if I switch off the TV I don't expect any eco
> > after ... I don't care about the program, it should not bother me.
>
> If you stick to the TV analogy... You don't want Tivo to erase what it
> just recorded just because you stopped recording.
>
> --
> erik
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: additional Math function

[Brendan Eich]

David Herman wrote:

On Nov 2, 2012, at 12:05 PM, Yehuda Katz  wrote:


Seems like a small surface-area with a large impact on compilers.

At first glance, looks good to me.

Curiosity: Does this overlap with Brendan's work on value objects (i.e. will it 
become moot in the face of them)


It could become unnecessary if you're working with value objects. If you had 
ordinary numbers, you'd have to coerce them to u32 and then multiply:

 var a = 0x7fff, b = 0x7fefefef; // both doubles
 var result = int32(a) * int32(b);   // int32

But value objects are still uncertain


I'm focusing on int64 and uint64 but making the framework as general 
under the hood as possible (e.g., the operators stuff, a multimethod 
variation that's inline-cacheable, based on an idea from Christian 
Plesner Hansen).


The need for 64-bit ints is pretty strong in Node.js and I think this 
means value objects are a priority for ES7.



  and at the very least much farther off into the future -- post-ES6. Engines 
could implement and ship Math.imul in very short order.


Agreed, and this kind of micro-evolution is important to support even 
while working on value objects for post-ES6. It may be we end up with 
int32 and uint32, but we don't need to if there's no strong use-case not 
satisfied by Math.imul.


Note that there's no micro-evolutionary step involving Math.imul64 that 
satisfies the int64/uint64 use-cases Node faces (buffer and file 
sizes/offsets). You need 64-bit addition, subtraction, and probably 
other operators -- and you need the data type, not just operations that 
could be Math methods.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Brendan Eich]

David Herman wrote:

 [Math.round(-0.1)].has(0) // false!


Could be a problem, but my position is that anyone using Math.round has 
to deal with -0. It is observably different from 0 via other Math 
functions, even if ===.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Asen Bozhilov]

Erik Arvidsson


>
> If we call it "has", should we also rename String.prototype.contains?
>
>
>
Most of the JS libraries use `has` method for checking property and key
existence. I am wondering if there is Array.prototype.has how they would
overload their `has` methods to work as expected with arrays, array-like
and regular native objects.  Also their is and
Object.prototype.hasOwnProperty. For example this code is a little bit
confusing for me:

var arr = [1, 2, 3];
arr.hasOwnProperty(0); //true
arr.has(0); //false
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: additional Math function

[David Herman]

On Nov 2, 2012, at 12:05 PM, Yehuda Katz  wrote:

> Seems like a small surface-area with a large impact on compilers.
> 
> At first glance, looks good to me.
> 
> Curiosity: Does this overlap with Brendan's work on value objects (i.e. will 
> it become moot in the face of them)

It could become unnecessary if you're working with value objects. If you had 
ordinary numbers, you'd have to coerce them to u32 and then multiply:

var a = 0x7fff, b = 0x7fefefef; // both doubles
var result = int32(a) * int32(b);   // int32

But value objects are still uncertain and at the very least much farther off 
into the future -- post-ES6. Engines could implement and ship Math.imul in very 
short order.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[David Herman]

On Nov 2, 2012, at 11:55 AM, Mark S. Miller  wrote:

> The only consistency issue is: should array.has agree with sense and all 
> other collections, or should it agree with array.indexOf / lastIndexOf. FWIW, 
> I would prefer not to add any more conveniences that further entrench 
> unexpected === checks.
> 
> 
> [NaN].has(NaN) // false
> 
> makes little sense.
> 
> [0.0].has(-0.0) // true
> 
> makes somewhat more sense, but not enough. Please let's either use add "has" 
> using SameValue or not add anything at all.

Sorry to complicate the opinion landscape further, but I'm not convinced that 
any collections should be using SameValue. Looking over my personal notes from 
an earlier conversation Mark and I had about maps and sets, I think we came to 
something where the default equivalence should be the tightest possible one 
(SameValue), but it should be possible to provide your own equality predicate 
as an optional constructor argument. We don't have that option for arrays.

There are plenty of operations that can result in a -0 without the programmer 
being aware, such as Math functions. I shudder to imagine debugging a program 
like this:

[Math.round(-0.1)].has(0) // false!

I agree that NaN should be equated, but I'm pretty nervous about the idea of 
distinguishing 0 and -0, especially when there's no way to override that 
behavior.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: additional Math function

[Yehuda Katz]

Seems like a small surface-area with a large impact on compilers.

At first glance, looks good to me.

Curiosity: Does this overlap with Brendan's work on value objects (i.e.
will it become moot in the face of them)

-- Yehuda Katz
(ph) 718.877.1325
On Nov 2, 2012 12:49 PM, "David Herman"  wrote:

> I'd like to add a Math.imul function for doing 32-bit integer
> multiplication. The use case is for compilers like Emscripten and Mandreel.
> They generate code to emulate machine operations that can be efficiently
> JIT compiled, but they don't currently have a good solution for doing
> integer multiplication. For other operations, like addition, they can use
> the composition of JS's floating-point addition and coercion to int32 via
> bitwise or:
>
> t = (a+b)|0;
>
> But you can't do the same trick with multiplication, because multiplying
> large numbers may lose low bits of precision when it overflows to double.
> So Emscripten has a compiler switch where you can do the fast-but-incorrect
> (a*b)|0 or you can do a slow-but-correct pure-JS multiply, which has to
> split the operation into two multiplications with manual carry. As it turns
> out, multiplication is the only major operation that doesn't have a clear
> implementation pattern with existing JS operators.
>
> The semantics is straightforward:
>
> Math.imul(a, b) === ToInt32((ToUint32(a) x ToUint32(b)) mod 2^32)
>
> In other words, convert the two arguments to 32-bit integers and "do what
> C does." The result is signed, simply as a convention -- signed and
> unsigned integers are isomorphic (ToUint32 and ToInt32 form the bijection
> between them). We could also consider adding Math.umul:
>
> Math.umul(a, b) === ToUint32((ToUint32(a) x ToUint32(b)) mod 2^32)
>
> but it's not strictly necessary; it's equivalent to:
>
> Math.imul(a, b)>>>0
>
> It might be nice to have Math.umul available out of the box, but for
> Emscripten and Mandreel, only one of the two is strictly necessary.
>
> At any rate, this function would be easy for JS engines to implement and
> optimize, and code generators could benefit from it immediately on engines
> that support it.
>
> I believe we could add this to the ES6 extended Math operations, because
> it's extremely simple and well-understood; there's no design necessary.
>
> Dave
>
> ___
> 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: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Erik Arvidsson]

On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi
 wrote:
> How to make this simple ... if I switch off the TV I don't expect any eco
> after ... I don't care about the program, it should not bother me.

If you stick to the TV analogy... You don't want Tivo to erase what it
just recorded just because you stopped recording.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Mark S. Miller]

Fortunately, strings cannot contain -0.0 or NaN, so neither string.contains
nor string.has sets any relevant precedent. FWIW, neither does
string.indexOf nor string.lastIndexOf.

The only consistency issue is: should array.has agree with sense and all
other collections, or should it agree with array.indexOf / lastIndexOf.
FWIW, I would prefer not to add any more conveniences that further entrench
unexpected === checks.


[NaN].has(NaN) // false

makes little sense.

[0.0].has(-0.0) // true

makes somewhat more sense, but not enough. Please let's either use add
"has" using SameValue or not add anything at all.



On Fri, Nov 2, 2012 at 11:04 AM, Rick Waldron wrote:

>
> On Friday, November 2, 2012 at 1:56 PM, Jason Orendorff wrote:
>
> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
> > If we call it "has", should we also rename String.prototype.contains?
>
> I'd say no; the distinction between collections "having" an element and
> strings "containing" a substring seems very sensible. It's a bit more
> awkward to say a string "has" a substring, and a string is definitely not a
> collection of substrings in any reasonable sense.
>
>
> Well, you could also note that array.has(x) looks for a particular value,
> while map.has(x) looks for a particular key.
>
> But that's not the point. There's no common formal contract implemented by
> all these methods; what they share is an informal "hey, look in this thing,
> and tell me if you see that thing" vibe.
>
> I like the idea of being able to say str.has(",") or str.has("=>") or
> str.has("@jorendorff") and have them all just work.
>
> This is definitely nice :)
>
> Jason, Erik, Mark,
>
> Any specific thoughts about the SameValue case as it likely doesn't apply
> to a hypothetical String.prototype.has impl.? I suspect that a string had
> would still use indexOf which would introduce an internal inconsistency for
> the sake of API consistency (which I'm all for). Unless I'm overlooking?
>
> Rick
>
>
>
> -j
>
> ___
> 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
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

additional Math function

[David Herman]

I'd like to add a Math.imul function for doing 32-bit integer multiplication. 
The use case is for compilers like Emscripten and Mandreel. They generate code 
to emulate machine operations that can be efficiently JIT compiled, but they 
don't currently have a good solution for doing integer multiplication. For 
other operations, like addition, they can use the composition of JS's 
floating-point addition and coercion to int32 via bitwise or:

t = (a+b)|0;

But you can't do the same trick with multiplication, because multiplying large 
numbers may lose low bits of precision when it overflows to double. So 
Emscripten has a compiler switch where you can do the fast-but-incorrect 
(a*b)|0 or you can do a slow-but-correct pure-JS multiply, which has to split 
the operation into two multiplications with manual carry. As it turns out, 
multiplication is the only major operation that doesn't have a clear 
implementation pattern with existing JS operators.

The semantics is straightforward:

Math.imul(a, b) === ToInt32((ToUint32(a) x ToUint32(b)) mod 2^32)

In other words, convert the two arguments to 32-bit integers and "do what C 
does." The result is signed, simply as a convention -- signed and unsigned 
integers are isomorphic (ToUint32 and ToInt32 form the bijection between them). 
We could also consider adding Math.umul:

Math.umul(a, b) === ToUint32((ToUint32(a) x ToUint32(b)) mod 2^32)

but it's not strictly necessary; it's equivalent to:

Math.imul(a, b)>>>0

It might be nice to have Math.umul available out of the box, but for Emscripten 
and Mandreel, only one of the two is strictly necessary.

At any rate, this function would be easy for JS engines to implement and 
optimize, and code generators could benefit from it immediately on engines that 
support it.

I believe we could add this to the ES6 extended Math operations, because it's 
extremely simple and well-understood; there's no design necessary.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Map|Set|WeakMap].prototype.isEmpty()?

[Rick Waldron]

On Fri, Nov 2, 2012 at 1:26 PM, Nicholas C. Zakas <
standa...@nczconsulting.com> wrote:

> I had mentioned this in passing in a previous email, but wanted to bring
> it up again.
>
> As I've been playing more with maps and sets, I've come to realize that I
> do this a lot:
>
> //note: FF implementation
> if (set.size() === 0) { ... }
>


*.size is a get accessor:

if ( !set.size ) {  }


Rick




> Basically, the only thing I've ever done with the size of one of these
> structures is compare it against zero, meaning that I've only ever cared if
> the structure was empty not necessarily how many items were contained
> within.
>
> I don't know if it's worthwhile or not, but I would personally love to see
> isEmpty() as a method on Map, Set, and WeakMap (maybe Array and String,
> too?). It seems to go along nicely with the clear() method on Map, Set, and
> WeakMap.
>
> -N
>
> --
> ___
> Nicholas C. Zakas
> http://www.nczonline.net
>
> __**_
> 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: Array.prototype.contains

[Erik Arvidsson]

http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has

On Fri, Nov 2, 2012 at 2:04 PM, Rick Waldron  wrote:
>
> On Friday, November 2, 2012 at 1:56 PM, Jason Orendorff wrote:
>
> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola
>  wrote:
>
>> If we call it "has", should we also rename String.prototype.contains?
>
> I'd say no; the distinction between collections "having" an element and
> strings "containing" a substring seems very sensible. It's a bit more
> awkward to say a string "has" a substring, and a string is definitely not a
> collection of substrings in any reasonable sense.
>
>
> Well, you could also note that array.has(x) looks for a particular value,
> while map.has(x) looks for a particular key.
>
> But that's not the point. There's no common formal contract implemented by
> all these methods; what they share is an informal "hey, look in this thing,
> and tell me if you see that thing" vibe.
>
> I like the idea of being able to say str.has(",") or str.has("=>") or
> str.has("@jorendorff") and have them all just work.
>
> This is definitely nice :)
>
> Jason, Erik, Mark,
>
> Any specific thoughts about the SameValue case as it likely doesn't apply to
> a hypothetical String.prototype.has impl.? I suspect that a string had would
> still use indexOf which would introduce an internal inconsistency for the
> sake of API consistency (which I'm all for). Unless I'm overlooking?
>
> Rick
>
>
>
> -j
>
> ___
> 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
>



-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Rick Waldron]

On Friday, November 2, 2012 at 1:56 PM, Jason Orendorff wrote:

> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola 
> mailto:dome...@domenicdenicola.com)> wrote:
> > > If we call it "has", should we also rename String.prototype.contains?
> > 
> > I'd say no; the distinction between collections "having" an element and 
> > strings "containing" a substring seems very sensible. It's a bit more 
> > awkward to say a string "has" a substring, and a string is definitely not a 
> > collection of substrings in any reasonable sense.
> 
> Well, you could also note that array.has(x) looks for a particular value, 
> while map.has(x) looks for a particular key.
> 
> But that's not the point. There's no common formal contract implemented by 
> all these methods; what they share is an informal "hey, look in this thing, 
> and tell me if you see that thing" vibe.
> 
> I like the idea of being able to say str.has(",") or str.has("=>") or 
> str.has("@jorendorff") and have them all just work.
This is definitely nice :)

Jason, Erik, Mark,

Any specific thoughts about the SameValue case as it likely doesn't apply to a 
hypothetical String.prototype.has impl.? I suspect that a string had would 
still use indexOf which would introduce an internal inconsistency for the sake 
of API consistency (which I'm all for). Unless I'm overlooking?

Rick 
 
> 
> -j
> 
> ___
> 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: Array.prototype.contains

[Jason Orendorff]

On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> > If we call it "has", should we also rename String.prototype.contains?
>
> I'd say no; the distinction between collections "having" an element and
> strings "containing" a substring seems very sensible. It's a bit more
> awkward to say a string "has" a substring, and a string is definitely not a
> collection of substrings in any reasonable sense.
>

Well, you could also note that array.has(x) looks for a particular value,
while map.has(x) looks for a particular key.

But that's not the point. There's no common formal contract implemented by
all these methods; what they share is an informal "hey, look in this thing,
and tell me if you see that thing" vibe.

I like the idea of being able to say str.has(",") or str.has("=>") or
str.has("@jorendorff") and have them all just work.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map/Set/WeakMap constructor genericity

[Allen Wirfs-Brock]

On Nov 2, 2012, at 8:54 AM, Jason Orendorff wrote:

> In the draft spec, you can basically turn any arbitrary object into a Map.
> 
> var obj = new Date;
> Map.call(obj);
> Map.prototype.set.call(obj, "x", "y");
> assert(Map.prototype.get.call(obj, "x") === "y");
> 
> The same object can be a Set too. Why not?
> 
> Set.call(obj, ["z"]);
> assert(Set.prototype.has.call(obj, "z"), true);
> 
> This is intended to make Map/Set/WeakMap subclassable, which is fine.  But 
> can we specify that without exposing Map initialization as a primitive that 
> users can apply to arbitrary objects?
> 
> As specified, a single object can have [[MapData]] and [[WeakMapData]] and 
> [[SetData]]. This is a pain to implement, and I don't see the benefit to web 
> developers.

Yes, indeed, although I believe the implementation can be less painful than you 
think.

Before I plunge into this, it may be helpful to review 
http://wiki.ecmascript.org/doku.php?id=strawman:subclassable-builtins 

I think you agree, that subclassability of built-ins is a valuable feature and 
that we want to avoid introducing any more non-subclassable built-ins (and, if 
possible, fix the existing ones so they are subclassable). So, it is a matter 
of how we can accomplish that.

Another design principle I've generally applied is that built-in "classes" 
should absolutely minimize their specialness.  We may have a built-in for perf 
or security reasons, to access an external resource that would not otherwise be 
accessible, to bridge to the implementation layer, to optimize runtime 
representations, etc.  But, where ever possible, the standard ES library should 
not be "magic".  It should be "self-hostable" in ECMAScript code.

So, if we follow that design principle in making Map and friends subclassable 
we  should do it in a manner that is consistent with what would be done in a 
self-hosted implementation.

One of the characteristics of creating class abstractions in JavaScript 
(whether manually or via a class declaration) is that object allocation is 
separated from object initialization.  The expression, new Foo, first allocates 
an ordinary object and then calls Foo to initialize it. Any specialness of the 
object derives not from its allocation but from the manner in which it is 
initialized.  For example, Foo might place a private symbol keyed property on 
the object to brand it as being a special Foo object.  Or, in the case of a Map 
object the Map constructor might associate special "MapData" internal state 
with the object via a private symbol keyed property. 

If we are going to subclass such a Foo (or Map) object (let's talk about a Bar 
subclass) the Bar constructor function needs to be able to able to call Foo to 
initialize the instance.  We do this by making a super call to Foo:
class Bar extends Foo {
   constructor() {
//maybe do some initialization on this here
super.constructor()}  //or just super(); either really means pretty 
much the same as Foo.call(this)
//maybe do some other initialization on this here
};

So, Foo has to be prepared to deal with an  arbitrary this object that may have 
already had some initialization performed upon it.  It also means that anybody 
who has visibility of Foo (via either a name binding or via the constructor 
property of a Foo instance ) can call Foo to initialize any arbitrary object. 
And there is nothing that prevents someone from call Foo, Bar, Map, and any 
other constructors all on the same object.  If the initialization actions 
performed by all of the constructors are disjoint then every thing should work 
just fine.  If the different constructors interfere with each other you will 
have a buggy object, but this is one of an infinite number of ways to define a 
buggy object.  Also note that calling multiple constructors  is not necessarily 
an unreasonable thing to do:  consider for example, a package that was 
supporting a multiple inheritance layer for JavaScript.

So, the possibility that an object may be initialized by multiple constructors 
as an inherent part of JavaScript and if we are following the 
builtins-aren't-magic principle we should expect this to apply to them as much 
as any other objects.

There is one way, to code classes so that allocation is coupled to 
initialization.  Move allocation into the constructor:

class Foo {
   constructor () {
   let self = Object.create(Object.getPrototypeOf(this));
   // initialize self
   return self;
   }
}

However, then a subclass has to be written as:
class Bar extends Foo {
   constructor() {
  let self = super();
  //initialize Bar state using self to reference the instance
  return self;
}
}

This seems error prone in may ways:  the subclass has to remember to  capture 
the result of the super.constructor call;  Constructors always need to end with 
an explicit return of self;  you have to avoid using this within constructors;  
you can't make super 

Re: Property Descriptors as script compatible representation

[David Bruant]

Le 02/11/2012 16:39, Allen Wirfs-Brock a écrit :
> So, yes, in that case Object.getOwnPropertyDescriptor and
> Object.defineProperty need to pass through object level descriptors
> from/to the corresponding proxy traps which means they can't normalize
> via a property descriptor record.  So, it is perfectly appropriate for
> them to explicitly test if O is a proxy and act accordingly.   I
> think, this should be the only place where an explicit Proxy test is
> required outside of the actual proxy object specification algorithms.
For some time after this sentence I wondered what justified
Object.getOwnPropertyDescriptor and Object.defineProperty to have
special-casing for proxies.
The reason is that proxies have an additional ability that regular
objects don't: accepting custom attributes. More specifically, proxies
are expected to be able to regurgitate custom attributes on
Object.getOwnPropertyDescriptor after they've been set with
Object.defineProperty.

Then, I wondered why it matters that only proxies can do it. The reason
is future-proofing. If a property descriptor record accepts any key and
value besides the standards ones, then it may become impossible to
extend property descriptor records in the future by assigning semantics
to currently-unused field names.

Keeping property descriptor records as tightly defined is for the best
for the future.

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Map|Set|WeakMap].prototype.isEmpty()?

[Andrea Giammarchi]

we are used to

`if (!arr.length) {  }`

so I don't see much different with collections and `size()`

Said that, I have bad feelings when I read "empty()" thinking about all
other set of inconsistencies famous in PHP world :-)


On Fri, Nov 2, 2012 at 10:26 AM, Nicholas C. Zakas <
standa...@nczconsulting.com> wrote:

> I had mentioned this in passing in a previous email, but wanted to bring
> it up again.
>
> As I've been playing more with maps and sets, I've come to realize that I
> do this a lot:
>
> //note: FF implementation
> if (set.size() === 0) { ... }
>
> Basically, the only thing I've ever done with the size of one of these
> structures is compare it against zero, meaning that I've only ever cared if
> the structure was empty not necessarily how many items were contained
> within.
>
> I don't know if it's worthwhile or not, but I would personally love to see
> isEmpty() as a method on Map, Set, and WeakMap (maybe Array and String,
> too?). It seems to go along nicely with the clear() method on Map, Set, and
> WeakMap.
>
> -N
>
> --
> ___
> Nicholas C. Zakas
> http://www.nczonline.net
>
> __**_
> 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: Array.prototype.contains

[Joshua Bell]

On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron  wrote:

>
> On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock 
> wrote:
>
>> There is also the compat issue with Mootools  with String contains...
>>
>> If we decided we needed to rename String contains then it might also
>> impact what we call a similar Array method
>>
>
> Perhaps it should be "has" instead of "contains"? Consistent with the
> other "collections".
>
>
If you dig back far enough in this thread [1], you'll see that one of the
motivations for suggesting this was to be able to obsolete DOMStringList
[2] and quietly switch existing methods to returning plain old Arrays. That
would argue for keeping the name as "contains".

But given that DOMStringList also has an explicit "items" method, and the
implications of the restriction to strings - e.g. calling d.contains(1) or
d.contains(undefined) follow WebIDL rules for stringifying the argument -
it is probably too late to actually remove DOMStringList from the platform.

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-February/020726.html
[2] http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMStringList
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Map|Set|WeakMap].prototype.isEmpty()?

[David Bruant]

It does not apply to WeakMaps, but otherwise, I agree it's a nice method
to have on Map and Set.

David

Le 02/11/2012 18:26, Nicholas C. Zakas a écrit :
> I had mentioned this in passing in a previous email, but wanted to
> bring it up again.
>
> As I've been playing more with maps and sets, I've come to realize
> that I do this a lot:
>
> //note: FF implementation
> if (set.size() === 0) { ... }
>
> Basically, the only thing I've ever done with the size of one of these
> structures is compare it against zero, meaning that I've only ever
> cared if the structure was empty not necessarily how many items were
> contained within.
>
> I don't know if it's worthwhile or not, but I would personally love to
> see isEmpty() as a method on Map, Set, and WeakMap (maybe Array and
> String, too?). It seems to go along nicely with the clear() method on
> Map, Set, and WeakMap.
>
> -N
>

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Array.prototype.contains

[Domenic Denicola]

-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On 
Behalf Of Erik Arvidsson
Sent: Friday, November 2, 2012 13:21

> If we call it "has", should we also rename String.prototype.contains?

I'd say no; the distinction between collections "having" an element and strings 
"containing" a substring seems very sensible. It's a bit more awkward to say a 
string "has" a substring, and a string is definitely not a collection of 
substrings in any reasonable sense.

If anyone had proposed String.prototype.has(singleCharOrMaybeCodePoint), then 
perhaps that name would make sense.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Andrea Giammarchi]

+1 ... but funny that for Strings I would naturally use "mychunk" in
mystring rather than mystring.has("mychunk")  I believe contains comes
from XSL, isn't it? Was it W3C suggestion or what?


On Fri, Nov 2, 2012 at 10:20 AM, Erik Arvidsson wrote:

> On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Miller 
> wrote:
> > I also support calling it "has" as Rick suggests. Perhaps this also helps
> > suggest that it is like the other "has"s, which use SameValue, and not
> like
> > indexOf.
> >
> > (I am still sad we did not fix indexOf, lastIndexOf, and switch when we
> > arguably had the chance.)
>
> If we call it "has", should we also rename String.prototype.contains?
>
> --
> erik
> ___
> 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

[Map|Set|WeakMap].prototype.isEmpty()?

[Nicholas C. Zakas]

I had mentioned this in passing in a previous email, but wanted to bring 
it up again.


As I've been playing more with maps and sets, I've come to realize that 
I do this a lot:


//note: FF implementation
if (set.size() === 0) { ... }

Basically, the only thing I've ever done with the size of one of these 
structures is compare it against zero, meaning that I've only ever cared 
if the structure was empty not necessarily how many items were contained 
within.


I don't know if it's worthwhile or not, but I would personally love to 
see isEmpty() as a method on Map, Set, and WeakMap (maybe Array and 
String, too?). It seems to go along nicely with the clear() method on 
Map, Set, and WeakMap.


-N

--
___
Nicholas C. Zakas
http://www.nczonline.net

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Rick Waldron]

On Fri, Nov 2, 2012 at 1:20 PM, Erik Arvidsson wrote:

> On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Miller 
> wrote:
> > I also support calling it "has" as Rick suggests. Perhaps this also helps
> > suggest that it is like the other "has"s, which use SameValue, and not
> like
> > indexOf.
> >
> > (I am still sad we did not fix indexOf, lastIndexOf, and switch when we
> > arguably had the chance.)
>
> If we call it "has", should we also rename String.prototype.contains?
>

Blitzed! I was just drafting a reply asking the same thing.

I think for consistency, yes... Although I'm not sure about using SameValue


Rick




> --
> erik
> ___
> 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: Array.prototype.contains

[Erik Arvidsson]

On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Miller  wrote:
> I also support calling it "has" as Rick suggests. Perhaps this also helps
> suggest that it is like the other "has"s, which use SameValue, and not like
> indexOf.
>
> (I am still sad we did not fix indexOf, lastIndexOf, and switch when we
> arguably had the chance.)

If we call it "has", should we also rename String.prototype.contains?

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[Andrea Giammarchi]

I've asked because I use this pattern quite a lot

Object.defineProperty({}, 'a', propValue(42))

function propValue(value) {
  // genericDescriptor define elsewhere
  genericDescriptor.value = value;
  return genericDescriptor;
}

obviously when it makes sense to reuse the descriptor. I define almost
everything through this pattern that when I've seen an extra constructor
around I've freaked out :D


On Fri, Nov 2, 2012 at 9:35 AM, Allen Wirfs-Brock wrote:

>
> On Nov 2, 2012, at 9:29 AM, Andrea Giammarchi wrote:
>
> I would add ... am I the only one that does not create a new object per
> each defined property ? I am recycling descriptor.value like hell, I wonder
> if anyone else out there is doing the same.
>
>
> Don't know what people are actually doing, but that usage mode was always
> envisioned when we designed property descriptor objects.
>
> Allen
>
>
>
>
>
>
>
>
>
> On Fri, Nov 2, 2012 at 1:31 AM, Tom Van Cutsem  wrote:
>
>> 2012/11/1 David Bruant 
>>
>>> The constructor I have proposed could have an equivalent initialization
>>> syntax.
>>> Object.defineProperty({}, 'a', PropDesc({value:42, writable:true}))
>>
>>
>> I see the merit in your proposal as making the Object->PropDesc
>> conversion explicit. However, I think it's too late for ES6:
>> Object.defineProperty must continue to accept Objects as its third
>> argument, and that's even shorter to write. So even if we would add such a
>> PropDesc constructor, I don't think most developers (including myself)
>> would adapt.
>>
>> Cheers,
>> Tom
>>
>> ___
>> 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
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Andrea Giammarchi]

I was wondering the same ... if `contains()` is the new indexOf then why
other collections are using `has()` ... I like has() more but it might be
me lazy typer ... still it should be consistent.


On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron  wrote:

>
>
> On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock 
> wrote:
>
>> There is also the compat issue with Mootools  with String contains...
>>
>> If we decided we needed to rename String contains then it might also
>> impact what we call a similar Array method
>>
>
>
> Perhaps it should be "has" instead of "contains"? Consistent with the
> other "collections".
>
> Rick
>
>
>>
>> Allen
>>
>>
>>
>> On Nov 2, 2012, at 8:19 AM, Erik Arvidsson wrote:
>>
>> I'll put up a proposal once electricity is back. I'll use the same
>> comparison as done in maps.
>> On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock" 
>> wrote:
>>
>>>
>>> On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
>>>
>>> Bump.
>>>
>>> I don't think Array.prototype.contains ever materialized on the
>>> "proposals" page, and hasn't shown up in an ES6 draft.
>>>
>>> Officially out for ES6, stuck in the queue, or dropped on the floor?
>>>
>>>
>>> Probably dropped on the floor, unless somebody can find something about
>>> it in meeting notes.
>>>
>>> It looks to me from scanning just this thread that it was an idea that
>>> was floated here with generally positive responses, but had some unresolved
>>> issues, and nobody ever signed on as champion to write an actual proposal.
>>>
>>> Allen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote:
>>>
 Allen, thank you for the clarification there


 Rick


 On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock 
 wrote:


 On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:



 On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson <
 erik.arvids...@gmail.com> wrote:

> DOM4 added a new interface called DOMStringList for the sole reason
> that Array does not have contains. Before this the return type was an
> Array of Strings so we could use indexOf, map, forEach etc. Now that
> it is using a non Array we lost all of that.
>

 Wouldn't the return type (or [[Class]]) still be restricted from using
 "Array"?

 From 8.6.2

 The value of the [[Class]] internal property is defined by this
 specification for every kind of built-in object. The value of the [[Class]]
 internal property of a host object may be any String value except one of
 "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
 "Math", "Number", "Object", "RegExp", and "String".


 So it can't be an "Array" by name, right?


 It can be, as long as it really is a ES array.  "host object" doesn't
 mean any object created by the host.  It means new kinds of objects created
 by the host that implement primitive behaviors (generally internal methods)
 differently from what is specified by the ES spec.

 So, from the ES perspective, no problem.  When I originally asked the
 question I was thinking more about from the Web IDL perspective.  Does Web
 IDL require things (for example throwing if extra arguments are passed)
 that ES Arrays do not do.


 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
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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: Property descriptors as ES6 Maps

[Allen Wirfs-Brock]

On Nov 2, 2012, at 9:29 AM, Andrea Giammarchi wrote:

> I would add ... am I the only one that does not create a new object per each 
> defined property ? I am recycling descriptor.value like hell, I wonder if 
> anyone else out there is doing the same.

Don't know what people are actually doing, but that usage mode was always 
envisioned when we designed property descriptor objects.

Allen







> 
> 
> On Fri, Nov 2, 2012 at 1:31 AM, Tom Van Cutsem  wrote:
> 2012/11/1 David Bruant 
> The constructor I have proposed could have an equivalent initialization
> syntax.
> Object.defineProperty({}, 'a', PropDesc({value:42, writable:true}))
> 
> I see the merit in your proposal as making the Object->PropDesc conversion 
> explicit. However, I think it's too late for ES6: Object.defineProperty must 
> continue to accept Objects as its third argument, and that's even shorter to 
> write. So even if we would add such a PropDesc constructor, I don't think 
> most developers (including myself) would adapt.
> 
> Cheers,
> Tom
> 
> ___
> 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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Mark S. Miller]

On Fri, Nov 2, 2012 at 8:19 AM, Erik Arvidsson wrote:

> I'll put up a proposal once electricity is back. I'll use the same
> comparison as done in maps.
>

With it being the same comparison as maps (which use SameValue), +1. Note
that this makes contains/has inconsistent with indexOf (which uses ===).

I also support calling it "has" as Rick suggests. Perhaps this also helps
suggest that it is like the other "has"s, which use SameValue, and not like
indexOf.

(I am still sad we did not fix indexOf, lastIndexOf, and switch when we
arguably had the chance.)


>  On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock" 
> wrote:
>
>>
>> On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
>>
>> Bump.
>>
>> I don't think Array.prototype.contains ever materialized on the
>> "proposals" page, and hasn't shown up in an ES6 draft.
>>
>> Officially out for ES6, stuck in the queue, or dropped on the floor?
>>
>>
>> Probably dropped on the floor, unless somebody can find something about
>> it in meeting notes.
>>
>> It looks to me from scanning just this thread that it was an idea that
>> was floated here with generally positive responses, but had some unresolved
>> issues, and nobody ever signed on as champion to write an actual proposal.
>>
>> Allen
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote:
>>
>>> Allen, thank you for the clarification there
>>>
>>>
>>> Rick
>>>
>>>
>>> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock 
>>> wrote:
>>>
>>>
>>> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>>>
>>>
>>>
>>> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson <
>>> erik.arvids...@gmail.com> wrote:
>>>
 DOM4 added a new interface called DOMStringList for the sole reason
 that Array does not have contains. Before this the return type was an
 Array of Strings so we could use indexOf, map, forEach etc. Now that
 it is using a non Array we lost all of that.

>>>
>>> Wouldn't the return type (or [[Class]]) still be restricted from using
>>> "Array"?
>>>
>>> From 8.6.2
>>>
>>> The value of the [[Class]] internal property is defined by this
>>> specification for every kind of built-in object. The value of the [[Class]]
>>> internal property of a host object may be any String value except one of
>>> "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
>>> "Math", "Number", "Object", "RegExp", and "String".
>>>
>>>
>>> So it can't be an "Array" by name, right?
>>>
>>>
>>> It can be, as long as it really is a ES array.  "host object" doesn't
>>> mean any object created by the host.  It means new kinds of objects created
>>> by the host that implement primitive behaviors (generally internal methods)
>>> differently from what is specified by the ES spec.
>>>
>>> So, from the ES perspective, no problem.  When I originally asked the
>>> question I was thinking more about from the Web IDL perspective.  Does Web
>>> IDL require things (for example throwing if extra arguments are passed)
>>> that ES Arrays do not do.
>>>
>>>
>>> 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
>>
>>
>>
>> ___
>> 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
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[Andrea Giammarchi]

I would add ... am I the only one that does not create a new object per
each defined property ? I am recycling descriptor.value like hell, I wonder
if anyone else out there is doing the same.


On Fri, Nov 2, 2012 at 1:31 AM, Tom Van Cutsem  wrote:

> 2012/11/1 David Bruant 
>
>> The constructor I have proposed could have an equivalent initialization
>> syntax.
>> Object.defineProperty({}, 'a', PropDesc({value:42, writable:true}))
>
>
> I see the merit in your proposal as making the Object->PropDesc conversion
> explicit. However, I think it's too late for ES6: Object.defineProperty
> must continue to accept Objects as its third argument, and that's even
> shorter to write. So even if we would add such a PropDesc constructor, I
> don't think most developers (including myself) would adapt.
>
> Cheers,
> Tom
>
> ___
> 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: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Andrea Giammarchi]

Main reason to use observe, in my opinion, is the ability to react on
changes. The moment an observer implements this "reacting logic" there's no
way it can work as expected if the object, or one of them, in the list of
records, is not observed anymore.

Let's say the object is not observed because not shadowing a DOM node for
whatever reason ... now let's say my observer gonna ask to perform so many
things because of a notification while it could simply "ignore/discards"
all those records being the object not "visible" or observed anymore.

How to make this simple ... if I switch off the TV I don't expect any eco
after ... I don't care about the program, it should not bother me.

Maybe the easiest way to avoid problems is to flag unobserved objects? But
here was my concern ... is Object.getNotifier(obj) the "official" way to
know if an object is being observed or not?


On Fri, Nov 2, 2012 at 9:14 AM, Rafael Weinstein wrote:

> Take for example:
>
> function myCallback(recs) {
>   console.log(recs.length);
> }
>
> var obj = {};
> Object.observe(obj, myCallback);
> obj.a = 1; // enqueues changeRecord
> obj.b = 2; // enqueues changeRecord
> Object.unobserve(obj, myCallback);
> obj.c = 3; // does not enqueue changeRecord
>
> 
>
> In the above example, myCallbacks will be invoked with two
> changeRecords and output
>
> > 2
>
> It sounds like you are worried about callbacks being delivered with
> changeRecords pointing to objects that they have stopped observing.
> This can and will happen. It's just something that users of the API
> need to understand. It doesn't strike me as a problem, but perhaps I'm
> missing something...?
>
> On Fri, Nov 2, 2012 at 5:04 PM, Andrea Giammarchi
>  wrote:
> > hey, thanks for coming back. The asynchronous unobserve in the meaning
> that
> > Object.unobserve is performed synchronously but the delivery of records
> is
> > asynchronous and performed regardless the object is not observed anymore.
> >
> > Inside the observer each record can point to an object that is no more
> > observed and I am not sure if there is a way to understand this or if the
> > observer should perform the getNotifier(obj) check.
> >
> > The way I would implement this is that when the Object.unobserve(obj) is
> > called, the queue, if any, with all previous records, is delivered at
> that
> > time, and not during the next tick.
> >
> > Thoughts?
> >
> >
> > On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein 
> > wrote:
> >>
> >> Andrea,
> >>
> >> I believe the example is correct. The way the API works is this:
> >>
> >> Object.observe and Object.unobserve both *synchronously*
> >> register/unregister your callback as observing/unobserving any given
> >> object. The asynchrony has to do with having changeRecords delivered
> >> -- that happens asynchronously.
> >>
> >> I don't understand the leak you are describing. Perhaps you can give a
> >> concrete example and how it goes wrong.
> >>
> >> On Thu, Nov 1, 2012 at 9:32 PM, Andrea Giammarchi
> >>  wrote:
> >> > Just wondering if this is actually meant/expected, I am talking about
> >> > the
> >> > example here:
> >> >
> >> > http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
> >> >
> >> > and the fact it should show something in console while in my opinion
> >> > that
> >> > should show nothing since the Object.unobserve is called in the same
> >> > "tick"
> >> >
> >> > Then I read the algo and I wonder if this won't create many problems,
> >> > i.e.
> >> > enabling a new way to leak objects through observers that should not
> be
> >> > called once the object is not observed anymore, specially because
> >> > there's no
> >> > way to understand if the object is observed or not, isn't it?
> >> >
> >> > Thanks for any sort of clarification.
> >> >
> >> > br
> >> >
> >> > ___
> >> > 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: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Rafael Weinstein]

Take for example:

function myCallback(recs) {
  console.log(recs.length);
}

var obj = {};
Object.observe(obj, myCallback);
obj.a = 1; // enqueues changeRecord
obj.b = 2; // enqueues changeRecord
Object.unobserve(obj, myCallback);
obj.c = 3; // does not enqueue changeRecord



In the above example, myCallbacks will be invoked with two
changeRecords and output

> 2

It sounds like you are worried about callbacks being delivered with
changeRecords pointing to objects that they have stopped observing.
This can and will happen. It's just something that users of the API
need to understand. It doesn't strike me as a problem, but perhaps I'm
missing something...?

On Fri, Nov 2, 2012 at 5:04 PM, Andrea Giammarchi
 wrote:
> hey, thanks for coming back. The asynchronous unobserve in the meaning that
> Object.unobserve is performed synchronously but the delivery of records is
> asynchronous and performed regardless the object is not observed anymore.
>
> Inside the observer each record can point to an object that is no more
> observed and I am not sure if there is a way to understand this or if the
> observer should perform the getNotifier(obj) check.
>
> The way I would implement this is that when the Object.unobserve(obj) is
> called, the queue, if any, with all previous records, is delivered at that
> time, and not during the next tick.
>
> Thoughts?
>
>
> On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein 
> wrote:
>>
>> Andrea,
>>
>> I believe the example is correct. The way the API works is this:
>>
>> Object.observe and Object.unobserve both *synchronously*
>> register/unregister your callback as observing/unobserving any given
>> object. The asynchrony has to do with having changeRecords delivered
>> -- that happens asynchronously.
>>
>> I don't understand the leak you are describing. Perhaps you can give a
>> concrete example and how it goes wrong.
>>
>> On Thu, Nov 1, 2012 at 9:32 PM, Andrea Giammarchi
>>  wrote:
>> > Just wondering if this is actually meant/expected, I am talking about
>> > the
>> > example here:
>> >
>> > http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
>> >
>> > and the fact it should show something in console while in my opinion
>> > that
>> > should show nothing since the Object.unobserve is called in the same
>> > "tick"
>> >
>> > Then I read the algo and I wonder if this won't create many problems,
>> > i.e.
>> > enabling a new way to leak objects through observers that should not be
>> > called once the object is not observed anymore, specially because
>> > there's no
>> > way to understand if the object is observed or not, isn't it?
>> >
>> > Thanks for any sort of clarification.
>> >
>> > br
>> >
>> > ___
>> > 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: Array.prototype.contains

[Rick Waldron]

On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock wrote:

> There is also the compat issue with Mootools  with String contains...
>
> If we decided we needed to rename String contains then it might also
> impact what we call a similar Array method
>


Perhaps it should be "has" instead of "contains"? Consistent with the other
"collections".

Rick


>
> Allen
>
>
>
> On Nov 2, 2012, at 8:19 AM, Erik Arvidsson wrote:
>
> I'll put up a proposal once electricity is back. I'll use the same
> comparison as done in maps.
> On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock"  wrote:
>
>>
>> On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
>>
>> Bump.
>>
>> I don't think Array.prototype.contains ever materialized on the
>> "proposals" page, and hasn't shown up in an ES6 draft.
>>
>> Officially out for ES6, stuck in the queue, or dropped on the floor?
>>
>>
>> Probably dropped on the floor, unless somebody can find something about
>> it in meeting notes.
>>
>> It looks to me from scanning just this thread that it was an idea that
>> was floated here with generally positive responses, but had some unresolved
>> issues, and nobody ever signed on as champion to write an actual proposal.
>>
>> Allen
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote:
>>
>>> Allen, thank you for the clarification there
>>>
>>>
>>> Rick
>>>
>>>
>>> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock 
>>> wrote:
>>>
>>>
>>> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>>>
>>>
>>>
>>> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson <
>>> erik.arvids...@gmail.com> wrote:
>>>
 DOM4 added a new interface called DOMStringList for the sole reason
 that Array does not have contains. Before this the return type was an
 Array of Strings so we could use indexOf, map, forEach etc. Now that
 it is using a non Array we lost all of that.

>>>
>>> Wouldn't the return type (or [[Class]]) still be restricted from using
>>> "Array"?
>>>
>>> From 8.6.2
>>>
>>> The value of the [[Class]] internal property is defined by this
>>> specification for every kind of built-in object. The value of the [[Class]]
>>> internal property of a host object may be any String value except one of
>>> "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
>>> "Math", "Number", "Object", "RegExp", and "String".
>>>
>>>
>>> So it can't be an "Array" by name, right?
>>>
>>>
>>> It can be, as long as it really is a ES array.  "host object" doesn't
>>> mean any object created by the host.  It means new kinds of objects created
>>> by the host that implement primitive behaviors (generally internal methods)
>>> differently from what is specified by the ES spec.
>>>
>>> So, from the ES perspective, no problem.  When I originally asked the
>>> question I was thinking more about from the Web IDL perspective.  Does Web
>>> IDL require things (for example throwing if extra arguments are passed)
>>> that ES Arrays do not do.
>>>
>>>
>>> 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
>>
>>
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Andrea Giammarchi]

hey, thanks for coming back. The asynchronous unobserve in the meaning that
Object.unobserve is performed synchronously but the delivery of records is
asynchronous and performed regardless the object is not observed anymore.

Inside the observer each record can point to an object that is no more
observed and I am not sure if there is a way to understand this or if the
observer should perform the getNotifier(obj) check.

The way I would implement this is that when the Object.unobserve(obj) is
called, the queue, if any, with all previous records, is delivered at that
time, and not during the next tick.

Thoughts?


On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein wrote:

> Andrea,
>
> I believe the example is correct. The way the API works is this:
>
> Object.observe and Object.unobserve both *synchronously*
> register/unregister your callback as observing/unobserving any given
> object. The asynchrony has to do with having changeRecords delivered
> -- that happens asynchronously.
>
> I don't understand the leak you are describing. Perhaps you can give a
> concrete example and how it goes wrong.
>
> On Thu, Nov 1, 2012 at 9:32 PM, Andrea Giammarchi
>  wrote:
> > Just wondering if this is actually meant/expected, I am talking about the
> > example here:
> >
> > http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
> >
> > and the fact it should show something in console while in my opinion that
> > should show nothing since the Object.unobserve is called in the same
> "tick"
> >
> > Then I read the algo and I wonder if this won't create many problems,
> i.e.
> > enabling a new way to leak objects through observers that should not be
> > called once the object is not observed anymore, specially because
> there's no
> > way to understand if the object is observed or not, isn't it?
> >
> > Thanks for any sort of clarification.
> >
> > br
> >
> > ___
> > 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

Map/Set/WeakMap constructor genericity

[Jason Orendorff]

In the draft spec, you can basically turn any arbitrary object into a Map.

var obj = new Date;
Map.call(obj);
Map.prototype.set.call(obj, "x", "y");
assert(Map.prototype.get.call(obj, "x") === "y");

The same object can be a Set too. Why not?

Set.call(obj, ["z"]);
assert(Set.prototype.has.call(obj, "z"), true);

This is intended to make Map/Set/WeakMap subclassable, which is fine.  But
can we specify that without exposing Map initialization as a primitive that
users can apply to arbitrary objects?

As specified, a single object can have [[MapData]] and [[WeakMapData]] and
[[SetData]]. This is a pain to implement, and I don't see the benefit to
web developers.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)

[Allen Wirfs-Brock]

On Nov 2, 2012, at 4:20 AM, Tom Van Cutsem wrote:

> Hi Allen,
> 
> 2012/11/1 Allen Wirfs-Brock 
> The above isn't how this will be expressed in the final spec.  Instead we 
> will have
> 
> 3) Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument name.
> 4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).
> 
> And all Proxy objects will have a [[GetOwnProperty]] internal methods that 
> looks something like:
> 
> 1) Let O be the object upon which this internal method was invoked.
> 2) Let desc be the result of calling TrapGetOwnProperty(O,name)
> 3) Return ToPropertyDescriptor(desc)
> 
> (I left out details of exception handling)
> 
> Actually, while reviewing the spec, I realized that there is a good reason 
> why the spec isn't currently specified this way (i.e. why the Proxy spec 
> redefines Object.defineProperty and Object.getOwnPropertyDescriptor and does 
> not just override [[DefineOwnProperty]] and [[GetOwnProperty]]) 
> 
> It is to avoid the lossy conversion that otherwise occurs between the return 
> value of [[GetOwnProperty]] and Object.getOwnPropertyDescriptor.
> 
> With your alternative spec above, consider a call to 
> |Object.getOwnPropertyDescriptor(proxy, name)|
> 
> 1. The Object.gOPD built-in calls proxy.[[GetOwnProperty]]
> 2. [[GetOwnProperty]] invokes the trap, gets back an object
> 3. [[GetOwnProperty]] converts the object into an internal descriptor and 
> returns
> 4. Object.gOPD takes this internal descriptor and turns it into an object 
> again
> 
> Not only are steps 3. and 4. logical inverses, they lose information: recall 
> that we had previously decided that custom attributes on property descriptors 
> would be passed through. So if a proxy trap returns the descriptor {value:42, 
> custom: true}, we want clients to still see the "custom" attribute. That's 
> why we need to avoid coercing the trap result to an internal descriptor.

Ah, yes.  I wondered about that and wasn't sure when I wrote the above whether 
we were allowing custom attributes. I figured you would speak up if that was an 
issue...

So, yes, in that case Object.getOwnPropertyDescriptor and Object.defineProperty 
need to pass through object level descriptors from/to the corresponding proxy 
traps which means they can't normalize via a property descriptor record.  So, 
it is perfectly appropriate for them to explicitly test if O is a proxy and act 
accordingly.   I think, this should be the only place where an explicit Proxy 
test is required outside of the actual proxy object specification algorithms.

> 
> The case for Object.defineProperty is entirely analogous.
> 
> That's why there exist TrapDefineOwnProperty and TrapGetOwnProperty auxiliary 
> functions: they abstract the common parts between the Object.* built-ins and 
> the internal methods without doing conversions. This is so that the Object.* 
> built-ins can call these auxiliaries directly, and avoid the conversions.
> 
> I realize you want to avoid explicit tests for proxies as much as possible. 
> One way to do that would be to introduce two new built-ins, so that we end up 
> with:
> [[GetOwnProperty]]( P ) -> PropDesc (same as ES5)
> [[GetOwnPropertyObject]] ( P) -> Object (called by Object.gOPD)
> [[DefineOwnProperty]] (P, PropDesc) -> Boolean (same as ES5)
> [[DefineOwnPropertyObject]] (P, Object) -> Boolean (called by 
> Object.defineProperty)
> 

No, we don't need the object variants.  We should only use "internal methods" 
were we need an algorithm to be polymorphically overloaded across multiple 
implementation level object representations.  In this case, it is only the 
proxy representation that needs the object variation so no polymorphic dispatch 
is required. Direct calls to your TrapGetOwn.../TrapDefine... routines is fine 
for the two places this actually occurs.

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Allen Wirfs-Brock]

There is also the compat issue with Mootools  with String contains...

If we decided we needed to rename String contains then it might also impact 
what we call a similar Array method

Allen


On Nov 2, 2012, at 8:19 AM, Erik Arvidsson wrote:

> I'll put up a proposal once electricity is back. I'll use the same comparison 
> as done in maps.
> 
> On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock"  wrote:
> 
> On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
> 
>> Bump.
>> 
>> I don't think Array.prototype.contains ever materialized on the "proposals" 
>> page, and hasn't shown up in an ES6 draft.
>> 
>> Officially out for ES6, stuck in the queue, or dropped on the floor?
> 
> Probably dropped on the floor, unless somebody can find something about it in 
> meeting notes.
> 
> It looks to me from scanning just this thread that it was an idea that was 
> floated here with generally positive responses, but had some unresolved 
> issues, and nobody ever signed on as champion to write an actual proposal.  
> 
> Allen
> 
> 
> 
> 
> 
> 
> 
>> 
>> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron  wrote:
>> Allen, thank you for the clarification there
>> 
>> 
>> Rick
>> 
>> 
>> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock  wrote:
>> 
>>> 
>>> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>>> 
 
 
 On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson  
 wrote:
 DOM4 added a new interface called DOMStringList for the sole reason
 that Array does not have contains. Before this the return type was an
 Array of Strings so we could use indexOf, map, forEach etc. Now that
 it is using a non Array we lost all of that.
 
 Wouldn't the return type (or [[Class]]) still be restricted from using 
 "Array"? 
 
 From 8.6.2
 
 The value of the [[Class]] internal property is defined by this 
 specification for every kind of built-in object. The value of the 
 [[Class]] internal property of a host object may be any String value 
 except one of "Arguments", "Array", "Boolean", "Date", "Error", 
 "Function", "JSON", "Math", "Number", "Object", "RegExp", and "String". 
 
 
 So it can't be an "Array" by name, right?
 
>>> 
>>> It can be, as long as it really is a ES array.  "host object" doesn't mean 
>>> any object created by the host.  It means new kinds of objects created by 
>>> the host that implement primitive behaviors (generally internal methods) 
>>> differently from what is specified by the ES spec.  
>>> 
>>> So, from the ES perspective, no problem.  When I originally asked the 
>>> question I was thinking more about from the Web IDL perspective.  Does Web 
>>> IDL require things (for example throwing if extra arguments are passed) 
>>> that ES Arrays do not do.
>>> 
>>> 
>>> 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
> 
> 
> ___
> 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: Array.prototype.contains

[Erik Arvidsson]

I'll put up a proposal once electricity is back. I'll use the same
comparison as done in maps.
On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock"  wrote:

>
> On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
>
> Bump.
>
> I don't think Array.prototype.contains ever materialized on the
> "proposals" page, and hasn't shown up in an ES6 draft.
>
> Officially out for ES6, stuck in the queue, or dropped on the floor?
>
>
> Probably dropped on the floor, unless somebody can find something about it
> in meeting notes.
>
> It looks to me from scanning just this thread that it was an idea that was
> floated here with generally positive responses, but had some unresolved
> issues, and nobody ever signed on as champion to write an actual proposal.
>
> Allen
>
>
>
>
>
>
>
>
> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote:
>
>> Allen, thank you for the clarification there
>>
>>
>> Rick
>>
>>
>> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock 
>> wrote:
>>
>>
>> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>>
>>
>>
>> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson > > wrote:
>>
>>> DOM4 added a new interface called DOMStringList for the sole reason
>>> that Array does not have contains. Before this the return type was an
>>> Array of Strings so we could use indexOf, map, forEach etc. Now that
>>> it is using a non Array we lost all of that.
>>>
>>
>> Wouldn't the return type (or [[Class]]) still be restricted from using
>> "Array"?
>>
>> From 8.6.2
>>
>> The value of the [[Class]] internal property is defined by this
>> specification for every kind of built-in object. The value of the [[Class]]
>> internal property of a host object may be any String value except one of
>> "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
>> "Math", "Number", "Object", "RegExp", and "String".
>>
>>
>> So it can't be an "Array" by name, right?
>>
>>
>> It can be, as long as it really is a ES array.  "host object" doesn't
>> mean any object created by the host.  It means new kinds of objects created
>> by the host that implement primitive behaviors (generally internal methods)
>> differently from what is specified by the ES spec.
>>
>> So, from the ES perspective, no problem.  When I originally asked the
>> question I was thinking more about from the Web IDL perspective.  Does Web
>> IDL require things (for example throwing if extra arguments are passed)
>> that ES Arrays do not do.
>>
>>
>> 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
>
>
>
> ___
> 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: Property Descriptors as script compatible representation

[Tom Van Cutsem]

2012/11/2 David Bruant 

>  Le 02/11/2012 12:20, Tom Van Cutsem a écrit :
>
> It is to avoid the lossy conversion that otherwise occurs between the
> return value of [[GetOwnProperty]] and Object.getOwnPropertyDescriptor.
>
> Just to be sure I fully understand: what is the loss exactly?
> I see that custom property descriptor attributes would be stripped out
> (because FromPropertyDescriptor outputs an object with 4 props mapping
> 1-to-1 to an accessor or data property descriptor).
> Is there another loss?
>

No, just the loss of custom attributes.


> If that's the only thing, redefining the property descriptor type to
> accept any field would prevent that loss. Such a change would be more
> aligned with the intention in the proxy spec of letting internal operations
> manipulate custom attributes passed to Object.defineProperty.
>
> I'm arguing in favor of switching to a script-usable type, but the change
> I mention can occur in the spec-only type.
>

I went ahead and refactored the Proxy spec to inline Aux.3
NormalizePropertyDescriptor and Aux.4
NormalizeAndCompletePropertyDescriptor [1]. The new behavior is identical
except that:
- both TrapGetOwnProperty and TrapDefineOwnProperty do one less needless
conversion from Object to PropDesc
- both TrapGetOwnProperty and TrapDefineOwnProperty can now do all
invariant checks against an internal PropDesc instead of against a
normalized property descriptor Object
- in TrapGetOwnProperty, we can defer conversion from PropDesc to Object,
and copying of custom attributes, to the last possible moment, only after
all the invariant checks succeed.

To my mind, this refactoring further reduces the need for some new
script-usable property descriptor type.

Cheers,
Tom

[1]
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec&rev=1349982638&do=diff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Rafael Weinstein]

Andrea,

I believe the example is correct. The way the API works is this:

Object.observe and Object.unobserve both *synchronously*
register/unregister your callback as observing/unobserving any given
object. The asynchrony has to do with having changeRecords delivered
-- that happens asynchronously.

I don't understand the leak you are describing. Perhaps you can give a
concrete example and how it goes wrong.

On Thu, Nov 1, 2012 at 9:32 PM, Andrea Giammarchi
 wrote:
> Just wondering if this is actually meant/expected, I am talking about the
> example here:
>
> http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
>
> and the fact it should show something in console while in my opinion that
> should show nothing since the Object.unobserve is called in the same "tick"
>
> Then I read the algo and I wonder if this won't create many problems, i.e.
> enabling a new way to leak objects through observers that should not be
> called once the object is not observed anymore, specially because there's no
> way to understand if the object is observed or not, isn't it?
>
> Thanks for any sort of clarification.
>
> br
>
> ___
> 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: Property Descriptors as script compatible representation

[David Bruant]

Le 02/11/2012 12:20, Tom Van Cutsem a écrit :
> Hi Allen,
>
> 2012/11/1 Allen Wirfs-Brock  >
>
> The above isn't how this will be expressed in the final spec.
>  Instead we will have
>
> 3) Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument name.
> 4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).
>
> And all Proxy objects will have a [[GetOwnProperty]] internal
> methods that looks something like:
>
> 1) Let O be the object upon which this internal method was invoked.
> 2) Let desc be the result of calling TrapGetOwnProperty(O,name)
> 3) Return ToPropertyDescriptor(desc)
>
> (I left out details of exception handling)
>
>
> Actually, while reviewing the spec, I realized that there is a good
> reason why the spec isn't currently specified this way (i.e. why
> the Proxy spec redefines Object.defineProperty and
> Object.getOwnPropertyDescriptor and does not just override
> [[DefineOwnProperty]] and [[GetOwnProperty]]) 
>
> It is to avoid the lossy conversion that otherwise occurs between the
> return value of [[GetOwnProperty]] and Object.getOwnPropertyDescriptor.
Just to be sure I fully understand: what is the loss exactly?
I see that custom property descriptor attributes would be stripped out
(because FromPropertyDescriptor outputs an object with 4 props mapping
1-to-1 to an accessor or data property descriptor).
Is there another loss?

If that's the only thing, redefining the property descriptor type to
accept any field would prevent that loss. Such a change would be more
aligned with the intention in the proxy spec of letting internal
operations manipulate custom attributes passed to Object.defineProperty.

I'm arguing in favor of switching to a script-usable type, but the
change I mention can occur in the spec-only type.

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)

[Tom Van Cutsem]

Hi Allen,

2012/11/1 Allen Wirfs-Brock 

> The above isn't how this will be expressed in the final spec.  Instead we
> will have
>
> 3) Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument name.
> 4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).
>
> And all Proxy objects will have a [[GetOwnProperty]] internal methods that
> looks something like:
>
> 1) Let O be the object upon which this internal method was invoked.
> 2) Let desc be the result of calling TrapGetOwnProperty(O,name)
> 3) Return ToPropertyDescriptor(desc)
>
> (I left out details of exception handling)
>

Actually, while reviewing the spec, I realized that there is a good reason
why the spec isn't currently specified this way (i.e. why the Proxy spec
redefines Object.defineProperty and Object.getOwnPropertyDescriptor and
does not just override [[DefineOwnProperty]] and [[GetOwnProperty]])

It is to avoid the lossy conversion that otherwise occurs between the
return value of [[GetOwnProperty]] and Object.getOwnPropertyDescriptor.

With your alternative spec above, consider a call to
|Object.getOwnPropertyDescriptor(proxy, name)|

1. The Object.gOPD built-in calls proxy.[[GetOwnProperty]]
2. [[GetOwnProperty]] invokes the trap, gets back an object
3. [[GetOwnProperty]] converts the object into an internal descriptor and
returns
4. Object.gOPD takes this internal descriptor and turns it into an object
again

Not only are steps 3. and 4. logical inverses, they lose information:
recall that we had previously decided that custom attributes on property
descriptors would be passed through. So if a proxy trap returns the
descriptor {value:42, custom: true}, we want clients to still see the
"custom" attribute. That's why we need to avoid coercing the trap result to
an internal descriptor.

The case for Object.defineProperty is entirely analogous.

That's why there exist TrapDefineOwnProperty and TrapGetOwnProperty
auxiliary functions: they abstract the common parts between the Object.*
built-ins and the internal methods without doing conversions. This is so
that the Object.* built-ins can call these auxiliaries directly, and avoid
the conversions.

I realize you want to avoid explicit tests for proxies as much as possible.
One way to do that would be to introduce two new built-ins, so that we end
up with:
[[GetOwnProperty]]( P ) -> PropDesc (same as ES5)
[[GetOwnPropertyObject]] ( P) -> Object (called by Object.gOPD)
[[DefineOwnProperty]] (P, PropDesc) -> Boolean (same as ES5)
[[DefineOwnPropertyObject]] (P, Object) -> Boolean (called by
Object.defineProperty)

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Descriptors as script compatible representation

[David Bruant]

Le 02/11/2012 09:33, Tom Van Cutsem a écrit :
> 2012/11/1 David Bruant mailto:bruan...@gmail.com>>
>
> Currently, TrapGetOwnProperty returns an object, but when there is an
> actual trap, it goes through:
> * NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6)
> * ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step
> 3 of
> NormalizeAndCompletePropertyDescriptor)
> * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
> NormalizeAndCompletePropertyDescriptor)
>
> We might as well get rid of the spec-only PropertyDescriptor,
> define an
> equivalently pre-condition/invariant enforcing ES5 construct and
> manipulate that both internally and in trap boundaries.
>
>
> I think the deal-breaker, as Allen pointed out, is that what you call
> an ESUsablePropDesc would still need to be mutable (if it wants to
> mimic current property-descriptors-as-objects-with-some-invariants).
Since the mutability would be limited by invariant enforcement, I don't
think it would be a problem. Maybe this problem is bigger than I see it?

> Plus, it doesn't get rid of the implicit conversions at proxy
> boundaries. In the case of defineProperty you'd still have to convert
> between a plain object passed in as 3rd arg, and an
> ESUsablePropDesc. In the case of getOwnPropertyDescriptor, to preserve
> current semantics, you must still copy the (mutable) ESUsablePropDesc
> to ensure that all calls to getOwnPropertyDescriptor return fresh,
> independent objects.
Arguably, if there is a construct that represent property descriptors,
it may no longer be necessary to return a fresh object each time.

> Thanks for drawing my attention to the auxiliary functions: it made me
> realize that Aux.3 NormalizePropertyDescriptor and Aux
> 4. NormalizeAndCompletePropertyDescriptor are only called in one
> place. I think that by in-lining their definitions we might get rid of
> some redundant conversions.
>
> That said, the "redundancy" you point out, i.e. the conversion from
> Object -> PropDesc immediately followed by PropDesc -> Object is not
> really redundant: it's needed to "normalize" the descriptor.
No. What's needed is an algorithm to normalize the descriptor. The
conversion is just a convenience to reuse the spec algorithm. The other
alternative would be to duplicate the logic to make it applicable to
ECMAScript objects.
I'm not satisfied with any of these choices (but apparently I'm the only
one)

> Implementations can probably optimize so that they don't actually have
> to allocate an intermediate internal property descriptor, but
> immediately create an Object copy.
Tell me if I'm wrong, but if implementations can get rid of the extra
allocation, so could the spec, no? (that's what Allen suggests in his
answer).

>  
>
> The way I see it now, ESUsablePropDesc would be a regular object
> with a
> bunch of getter/setters to enforce property descriptor invariants.
> Everything would remain compatible (unless people really cared
> that ES5
> descriptors have data properties).
>
>
> Unfortunately it's not a question of caring: currently, an ES5
> meta-program can make the valid assumption that all "standard"
> attributes of a property descriptor object are data properties.
> Changing this assumption is not backwards-compatible.
... but it may be a corner-case that can be changed if not depended upon
by content on the web. It has happen many times already. Whether it can
be done in this particular case would require research.

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)

[Tom Van Cutsem]

2012/11/1 David Bruant 

> Currently, TrapGetOwnProperty returns an object, but when there is an
> actual trap, it goes through:
> * NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6)
> * ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step 3 of
> NormalizeAndCompletePropertyDescriptor)
> * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
> NormalizeAndCompletePropertyDescriptor)
>
> We might as well get rid of the spec-only PropertyDescriptor, define an
> equivalently pre-condition/invariant enforcing ES5 construct and
> manipulate that both internally and in trap boundaries.
>

I think the deal-breaker, as Allen pointed out, is that what you call an
ESUsablePropDesc would still need to be mutable (if it wants to mimic
current property-descriptors-as-objects-with-some-invariants).

Plus, it doesn't get rid of the implicit conversions at proxy
boundaries. In the case of defineProperty you'd still have to convert
between a plain object passed in as 3rd arg, and an ESUsablePropDesc. In
the case of getOwnPropertyDescriptor, to preserve current semantics, you
must still copy the (mutable) ESUsablePropDesc to ensure that all calls to
getOwnPropertyDescriptor return fresh, independent objects.

Granted, having an ESUsablePropDesc would avoid conversions in the case of
proxies forwarding the operation to their target.

Thanks for drawing my attention to the auxiliary functions: it made me
realize that Aux.3 NormalizePropertyDescriptor and Aux
4. NormalizeAndCompletePropertyDescriptor are only called in one place. I
think that by in-lining their definitions we might get rid of some
redundant conversions.

That said, the "redundancy" you point out, i.e. the conversion from Object
-> PropDesc immediately followed by PropDesc -> Object is not really
redundant: it's needed to "normalize" the descriptor. Implementations can
probably optimize so that they don't actually have to allocate an
intermediate internal property descriptor, but immediately create an Object
copy.


> The way I see it now, ESUsablePropDesc would be a regular object with a
> bunch of getter/setters to enforce property descriptor invariants.
> Everything would remain compatible (unless people really cared that ES5
> descriptors have data properties).


Unfortunately it's not a question of caring: currently, an ES5 meta-program
can make the valid assumption that all "standard" attributes of a property
descriptor object are data properties. Changing this assumption is not
backwards-compatible.

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[Tom Van Cutsem]

2012/11/1 David Bruant 

> The constructor I have proposed could have an equivalent initialization
> syntax.
> Object.defineProperty({}, 'a', PropDesc({value:42, writable:true}))


I see the merit in your proposal as making the Object->PropDesc conversion
explicit. However, I think it's too late for ES6: Object.defineProperty
must continue to accept Objects as its third argument, and that's even
shorter to write. So even if we would add such a PropDesc constructor, I
don't think most developers (including myself) would adapt.

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss