Re: Minimal Module System Proposal

2013-02-12 Thread Brendan Eich

Kevin Smith wrote:


 Variant B: "module =" syntax

Is that the variant you favor?


Yes, because:

- It aligns the URL visually to the right, which is consistent with 
the import syntax.


- It makes it clear that we are binding an identifier to a (possibly 
external) module, as opposed to importing bindings from a module.  I 
think we should avoid overloaded terminology where "import" can also 
mean "load".


I like it best too, for those reasons.

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


Re: Minimal Module System Proposal

2013-02-12 Thread Kevin Smith
 Variant B: "module =" syntax
>
> Is that the variant you favor?


Yes, because:

- It aligns the URL visually to the right, which is consistent with the
import syntax.

- It makes it clear that we are binding an identifier to a (possibly
external) module, as opposed to importing bindings from a module.  I think
we should avoid overloaded terminology where "import" can also mean "load".

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


Re: Minimal Module System Proposal

2013-02-12 Thread Brendan Eich

Kevin Smith wrote:


Thanks, but let's not jump to any conclusions. I'm the champion of
modules and wasn't even able to be a part of the discussion for
family reasons. We can't make any judgment about the status of
modules, or plans for reacting to the status of modules, before
I've had a chance to be a part of the conversation.


 +1 and congrats (I'm slinging a babe right now ; )

I'm confident that modules will make it - in my mind ES6 will fail if 
not.  They are certainly more important than proxies and private 
names, and the sooner we coalesce around the syntax, the better 
everyone will feel.  IMO, your previous proposal was almost right on. 
 e.g.


http://wiki.ecmascript.org/doku.php?id=harmony:modules&rev=1332511079 


https://gist.github.com/khs4473/4382710

I think we need to have a knock-down-drag-out discussion about URL and 
loader semantics.  ; )


Question about the linked wiki page rev:


 Variant B: "module =" syntax

Is that the variant you favor?

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


Re: Private symbols vs property attributes

2013-02-12 Thread Mark S. Miller
Yes. During a break at TC39 I sketched a very nice diagram of this to,
IIRC, Rick. I stupidly did not take a photo. When I find the time I'll try
to reproduce. In the meantime, hopefully the idea is clear enough.


On Tue, Feb 12, 2013 at 7:23 AM, David Bruant  wrote:

> Le 12/02/2013 16:06, Andreas Rossberg a écrit :
>
>  On 10 February 2013 19:40, Mark Miller  wrote:
>>
>>> How does this interact with Proxies[1]? I know the answer probably starts
>>> with "whitelist", but let's spell it out in this context, and test it
>>> against the 8 membrane transparency cases previously discussed. If there
>>> are
>>> good answers for all of these, and if we can reuse enumerable: for this
>>> purpose as Brendan suggests, then I'm guardedly positive. I do not want
>>> to
>>> introduce a new attribute.
>>>
>> I must have missed the discussion of the "8 membrane transparency
>> cases". Do you have a pointer?
>>
> I think it is https://mail.mozilla.org/**pipermail/es-discuss/2013-**
> January/028481.html
>
> David
>



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


Re: Class Method Syntax

2013-02-12 Thread Brendan Eich

Domenic Denicola wrote:

Oooh, static getters and setters, nice.

Glad to see the max-min idea seems to be working out well:). Little incremental 
improvements like this seem natural and a joy to use. Awesome to see them in 
Traceur so quickly too!


Yes, this is great! All praise to Arv (and keep putting the C++ engines 
to shame ;-).


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


Re: Private symbols vs property attributes

2013-02-12 Thread Brendan Eich

Andreas Rossberg wrote:

I'm fine with reusing 'enumerable'. Finally, a useful function for
that attribute.:)


You and everyone else!

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


RE: Class Method Syntax

2013-02-12 Thread Domenic Denicola
Oooh, static getters and setters, nice.

Glad to see the max-min idea seems to be working out well :). Little 
incremental improvements like this seem natural and a joy to use. Awesome to 
see them in Traceur so quickly too!

From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf 
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Tuesday, February 12, 2013 10:49
To: Kevin Smith
Cc: es-discuss
Subject: Re: Class Method Syntax

On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith  wrote:
> First, thanks for creating a proposal for this.  A couple of questions:
>
> 1)  Is class method syntax slated for ES6?

Yes.

> 2)  I assume that we'd parse "static" the same way we parse "get" and "set",
> e.g. this is possible:
>
> class C {
> static() {} // Method "static" on C instance
> static static() {} // Method "static" on C
> }

Yes.

https://code.google.com/p/traceur-compiler/source/browse/test/feature/Classes/Static.js#23

--
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: Class Method Syntax

2013-02-12 Thread Erik Arvidsson
On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith  wrote:
> First, thanks for creating a proposal for this.  A couple of questions:
>
> 1)  Is class method syntax slated for ES6?

Yes.

> 2)  I assume that we'd parse "static" the same way we parse "get" and "set",
> e.g. this is possible:
>
> class C {
> static() {} // Method "static" on C instance
> static static() {} // Method "static" on C
> }

Yes.

https://code.google.com/p/traceur-compiler/source/browse/test/feature/Classes/Static.js#23

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


Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

2013-02-12 Thread Claus Reinke
[to limit the length of my reply, I had to avoid responding to every 
detail, trying to answer the gist of your message instead; please let 
me know if I missed anything important]



Of course, you might argue that I could just call it like:

 NodeList.from( [ "div", "span", "p" ].map(nodeName =>
document.createElement(nodeName)) );


Indeed, this would be my preferred choice. It would be more modular
than packaging the combination of container change and element
conversion into a single operation.

However, I understand the conflict between type-changing element 
maps and element-type-constrained containers. 

Let me change the example to bring out this point: if we convert from 
an array of Int32 to an array of Double, we cannot map on the source 
array nor can we map on the target array. So we do have to map the 
elements in transit, after extracting them from the Int32 source and 
before placing them in the Double target, preferably without creating

an intermediate Array.

Since the container change (.from()) is specced via iterators, I suggest
to ensure support for .map() on iterators and map the elements in the
iteration, after extraction from source, before integration into target.

Integrating the element map into the container conversion (.from())
instead, which is a static method to enforce target-type specification,
solves the issue you were trying to address, for Array subclasses, but
it leaves us with a host of residual issues:

- there are now two operations for one generic task, 
Array.prototype.map(  )// type-preserving

   .from( ,  ) // type-changing

- the two -clearly related- operations do not have a common interface,
   in fact, one is an object method, the other a static/class method

- the latter operation is really a family of operations, and the static
   type prefixes of the family members are difficult to abstract over 
   (do I try to get the target type from the target object context or 
   from the function result, or do I force the user to pass it in at 
   every call site)


- even with this additional complexity, we still do not have support
   for mapping over the elements of other, non-Array containers

I suspect that the problem of establishing target container types 
is separate from the element mapping, so I would like to keep

.from() and .map() separate. But even in the merged design
programming will be awkward.

...But the "arraylike" or "iterable" might not have a .map() method 
of its own, which will cause issues if I'm in a JS-target transpilation 
scenario...


And I would like not only to root out any "arraylike" or "iterable"
that do not support .map(), but would also like to extend the reach
of .map() to other cases where it makes sense (I've listed examples
in previous messages).


(function( root ) {
 root.converter = function( ctor, iterable, map ) {
   return this[ ctor ].from( iterable, map );
 }.bind(root);
}( this ));


What you're saying here is that (1) .from() should support .map()-like
functionality for all iterables (even if they do not support .map()), that 
(2) we can't use .map() because it may not be supported for all iterables 
and the 'map' parameter might be type-changing, and that (3) you 
don't know how to get the target type generically, so it'll have to be 
passed in at each call site. 


None of this is promising when I think of writing generic code that
employs mapping over different container types, even if we assume
that the mapping .from() replaces .map() as the general interface.

Are you going to pass around 'ctor's as dynamic type hints? Since
we need the target classes, we can't even extract the class from
the source arrays. This, and the inability to de-structure things
like Int32Array into its components, are among the outstanding 
language design issues generated in this area.



My point was that map is far more widely useful, not limited to
Array (Array.prototype.map), and not limited to Array construction
from Iterables (Array.prototype.from with second parameter). 
Consider map on event emitters, on promises, on exceptions, on 
generators, ..


I don't have an alternative solution that would cover all use cases 
in ES uniformly, because the existing solutions in other languages

do not translate directly.
However, I wanted to ring a warning bell that adding a different 
partial solution for every new use case is not going to scale well 
(especially with things being so difficult to change once they are 
in ES), and misses potential for writing generic library code.


Can you show an example of this?


Example of what (can't resolve 'this';-)? I listed several examples of 
classes that I'd like to see map() support on. You gave an example 
of how you couldn't write generic code using map() because not 
all relevant classes support that method (using .from() on iterables 
doesn't work, either). If you mean difficulties of evolving ES designs

after release, think no further than existing code inheriting from
Arr

Re: Private symbols vs property attributes

2013-02-12 Thread David Bruant

Le 12/02/2013 16:06, Andreas Rossberg a écrit :

On 10 February 2013 19:40, Mark Miller  wrote:

How does this interact with Proxies[1]? I know the answer probably starts
with "whitelist", but let's spell it out in this context, and test it
against the 8 membrane transparency cases previously discussed. If there are
good answers for all of these, and if we can reuse enumerable: for this
purpose as Brendan suggests, then I'm guardedly positive. I do not want to
introduce a new attribute.

I must have missed the discussion of the "8 membrane transparency
cases". Do you have a pointer?
I think it is 
https://mail.mozilla.org/pipermail/es-discuss/2013-January/028481.html


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


Re: Class Method Syntax

2013-02-12 Thread Rick Waldron
At the last TC39 meeting, Yehuda Katz presented a proposal that was
accepted for ES6:

https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md#staticclass-side-methods

Rick


On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith  wrote:

> First, thanks for creating a proposal for this.  A couple of questions:
>
> 1)  Is class method syntax slated for ES6?
>
> 2)  I assume that we'd parse "static" the same way we parse "get" and
> "set", e.g. this is possible:
>
> class C {
> static() {} // Method "static" on C instance
> static static() {} // Method "static" on C
> }
>
> Thanks!
>
> { Kevin }
>
> ___
> 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: Private symbols vs property attributes

2013-02-12 Thread Andreas Rossberg
On 10 February 2013 19:40, Mark Miller  wrote:
> How does this interact with Proxies[1]? I know the answer probably starts
> with "whitelist", but let's spell it out in this context, and test it
> against the 8 membrane transparency cases previously discussed. If there are
> good answers for all of these, and if we can reuse enumerable: for this
> purpose as Brendan suggests, then I'm guardedly positive. I do not want to
> introduce a new attribute.

I must have missed the discussion of the "8 membrane transparency
cases". Do you have a pointer?

I'm fine with reusing 'enumerable'. Finally, a useful function for
that attribute. :)

/Andreas


> [1] For now, I agree that the proxies we should examine are direct proxies.
>
>
> On Sun, Feb 10, 2013 at 9:30 AM, David Bruant  wrote:
>>
>> Le 10/02/2013 17:16, Mark S. Miller a écrit :
>>
>>> I do not understand what is being proposed. When I try to imagine a
>>> proposal starting from what has been said, I have not been able to imagine
>>> something that works. But that's not a criticism. What is this alternate
>>> privacy idea?
>>
>> My understanding is:
>> * there is only one kind of symbol
>> * whether the symbol is reflected by Object.getOwnPropertyNames and the
>> likes is controlled by a 'private' attribute in property descriptors.
>>
>> // unique constructor, no boolean since there is only one kind of
>> symbol
>> var s = new Symbol();
>> var o = {}, o2 = {};
>>
>> Object.defineProperty(o, s, {value: 12, private: true});
>> assert(Object.getOwnPropertyNames(o).length === 0)
>> assert(o[s] === 12);
>> o[s] = 31;
>> assert(o[s] === 31);
>>
>> Object.defineProperty(o2, s, {value: 7, private: false});
>> assert(Object.getOwnPropertyNames(o)[0] === s);
>> assert(o2[s] === 7);
>> o2[s] = 13;
>> assert(o2[s] === 13);
>>
>> Pending question:
>> var o3 = {};
>> o3[s] = 62;
>> Object.getOwnPropertyDescriptor(o3, s).private // true or false?
>>
>> Since private:false implies symbol sharing through
>> Object.getOwnPropertyDescriptor, I think private:true should be favored to
>> force people to be explicit (see my reply to Brendan)
>>
>> The main difference with the current proposal is that privacy isn't an
>> inherent characteristic of the symbol, but related to how it's been
>> configured on the different objects it's been used on.
>>
>> Was the above one of the things you imagined? If yes, why doesn't it work?
>>
>> David
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> ___
> 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: Private symbols vs property attributes

2013-02-12 Thread Kevin Smith
> I have come to think that this distinction is backwards. It is
> attributing something to symbols that actually is an attribute of
> properties. Symbols are just symbols. We should not piggyback them
> with something that is not actually related to their own semantics as
> such, but only their forwarding in specific client contexts.
>

Agreed - thanks for sharing this perspective.  I think that regardless of
what happens with respect to private state, we must only have one kind of
symbol.

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


Class Method Syntax

2013-02-12 Thread Kevin Smith
First, thanks for creating a proposal for this.  A couple of questions:

1)  Is class method syntax slated for ES6?

2)  I assume that we'd parse "static" the same way we parse "get" and
"set", e.g. this is possible:

class C {
static() {} // Method "static" on C instance
static static() {} // Method "static" on C
}

Thanks!

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


Re: A case for removing the seal/freeze/isSealed/isFrozen traps

2013-02-12 Thread Brendan Eich
Loss of identity, extra allocations, and forwarding overhead remain 
problems.


It seems to me that you are focusing too much on "share ... to untrusted 
parties." It's true you want either a membrane or an already-frozen 
object in such a setting. But the latter case, already-frozen object, 
does not want a membrane, both to avoid identity change and to avoid the 
allocation and forwarding overheads. And outside of untrusted parties, 
frozen objects have their uses -- arguably more over time with safe 
parallelism in JS.


/be

David Bruant wrote:

Hi,

The main use case (correct me if I'm wrong) for freezing/sealing an 
object is sharing an object to untrusted parties while preserving the 
object integrity. There is also the tamper-proofing of objects 
everyone has access to (Object.prototype in the browser)


In a world with proxies, it's easy to build new objects with high 
integrity without Object.freeze: build your object, share only a 
wrapped version to untrusted parties, the handler takes care of the 
integrity.


function thrower(){
throw new Error('nope');
}
var frozenHandler = {
set: thrower,
defineProperty: thrower,
delete: thrower
};

function makeFrozen(o){
return new Proxy(o, frozenHandler);
}

This is true to a point that I wonder why anyone would call 
Object.freeze on script-created objects any longer... By design and 
for good reasons, proxies are a subset of "script-created objects", so 
my previous sentence contained: "I wonder why anyone would call 
Object.freeze on proxies..."


There were concerned about Object.freeze/seal being costly on proxies 
if defined as preventExtension + enumerate + nbProps*defineProperty. 
Assuming Object.freeze becomes de-facto deprecated in favor of 
proxy-wrapping for high-integrity use cases, maybe that cost is not 
that big of a deal.


David
___
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


A case for removing the seal/freeze/isSealed/isFrozen traps

2013-02-12 Thread David Bruant

Hi,

The main use case (correct me if I'm wrong) for freezing/sealing an 
object is sharing an object to untrusted parties while preserving the 
object integrity. There is also the tamper-proofing of objects everyone 
has access to (Object.prototype in the browser)


In a world with proxies, it's easy to build new objects with high 
integrity without Object.freeze: build your object, share only a wrapped 
version to untrusted parties, the handler takes care of the integrity.


function thrower(){
throw new Error('nope');
}
var frozenHandler = {
set: thrower,
defineProperty: thrower,
delete: thrower
};

function makeFrozen(o){
return new Proxy(o, frozenHandler);
}

This is true to a point that I wonder why anyone would call 
Object.freeze on script-created objects any longer... By design and for 
good reasons, proxies are a subset of "script-created objects", so my 
previous sentence contained: "I wonder why anyone would call 
Object.freeze on proxies..."


There were concerned about Object.freeze/seal being costly on proxies if 
defined as preventExtension + enumerate + nbProps*defineProperty. 
Assuming Object.freeze becomes de-facto deprecated in favor of 
proxy-wrapping for high-integrity use cases, maybe that cost is not that 
big of a deal.


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


Re: bis - Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

2013-02-12 Thread Aymeric Vitte
and, I forgot and don't know exactly if this should fall here, a 
toString(encoding) method which supports streaming, see [3] using 
TextEncoder/TextDecoder


Le 12/02/2013 12:54, Aymeric Vitte a écrit :


Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :


All the presentation decks from the meeting are publicly available at 
http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013


the short form:

In ES5, today you can use Array.prototype as the [[Prototype]] of 
non-Array objects or apply the Array.prototype methods to non-arrays. 
 The behaviors they get are non-necessarily what you would expect if 
you would really subclass Array.  We need to preserve the existing 
behaviors for these existing use cases but would like to provide the 
more reasonable behavior when class extends Array is used to create a 
subclass.


Array.prototype.concat is the most problematic of the existing 
methods in this regard.


After reading this thread and the slides, what is the plan for Typed 
Arrays (dedicated array like methods or Array subclassed like) ?


I see the constraints for subclassing, but the solution a.from(b,map) 
seems a little bit strange (even if I agree that it should return the 
same instance as a) , and what about concat, slice, etc as you 
mention? Couldn't we add something like a parameter to the methods : 
example.map(f,thisArg, true) or example.map(f,true) returns example's 
instance instead of Array (same processing as .of, .from), so you can 
explicitely say that you want to return the same instance and don't 
have backward compatilities issues (hopefully...) ?


I have used a lot Typed Arrays for [1] [2] [3] and all along wondering 
why Array like optimized methods were not available, especially 
concat, and why it was speced entirely in TC39 while a spec already 
exists (which specifies slice/subarray but surprisingly not concat), 
but it will be extremely usefull to have the Array like methods in the 
ES specs for Typed Arrays.


Regards,

[1] https://www.github.com/Ayms/node-Tor
[2] https://www.github.com/Ayms/iAnonym
[3] https://www.github.com/Ayms/node-typedarray




--
jCore
Email :  avi...@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

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


Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

2013-02-12 Thread Aymeric Vitte


Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :


All the presentation decks from the meeting are publicly available at 
http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013


the short form:

In ES5, today you can use Array.prototype as the [[Prototype]] of 
non-Array objects or apply the Array.prototype methods to non-arrays. 
 The behaviors they get are non-necessarily what you would expect if 
you would really subclass Array.  We need to preserve the existing 
behaviors for these existing use cases but would like to provide the 
more reasonable behavior when class extends Array is used to create a 
subclass.


Array.prototype.concat is the most problematic of the existing methods 
in this regard.


After reading this thread and the slides, what is the plan for Typed 
Arrays (dedicated array like methods or Array subclassed like) ?


I see the constraints for subclassing, but the solution a.from(b,map) 
seems a little bit strange (even if I agree that it should return the 
same instance as a) , and what about concat, slice, etc as you mention? 
Couldn't we add something like a parameter to the methods : 
example.map(f,thisArg, true) or example.map(f,true) returns example's 
instance instead of Array (same processing as .of, .from), so you can 
explicitely say that you want to return the same instance and don't have 
backward compatilities issues (hopefully...) ?


I have used a lot Typed Arrays for [1] [2] [3] and all along wondering 
why Array like optimized methods were not available, especially concat, 
and why it was speced entirely in TC39 while a spec already exists 
(which specifies slice/subarray but surprisingly not concat), but it 
will be extremely usefull to have the Array like methods in the ES specs 
for Typed Arrays.


Regards,

[1] https://www.github.com/Ayms/node-Tor
[2] https://www.github.com/Ayms/iAnonym
[3] https://www.github.com/Ayms/node-typedarray

--
jCore
Email :  avi...@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

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


Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

2013-02-12 Thread Herby Vojčík



Rick Waldron wrote:



On Monday, February 11, 2013, Nathan Wall wrote:

Thank you for this explanation.  This is very interesting!  If you
don't mind, I have some questions/concerns I'd like to clear up.
  (In particular I want to make sure I understand; I don't intend to
argue for one side or the other ATM, but this change may require me
to refactor some old code to be future-ready).

Allen Wirfs-Brock wrote:
 > The choice we agreed to, at the meeting is
 >
 > 1) Array.prototype.map produces the same kind of array that it
was applied to, so:
 >
 > for the above example
 > m instance of V will be true.
 > intArray.map(v=>v.toSring()) produces an Int32Array. The strings
produced by the map function get converted back to numbers.

Sounds cool! Does it work?

I rely on the genericness of Array methods quite a lot. For example,
it's fairly common for me to write something like the following:

 var map = Function.prototype.call.bind(Array.prototype.map),
 select = document.querySelectorAll.bind(document);

 var ids = map(select('div'), function(el) { return el.id
; });

Currently this would get me an array of string ids for every div on
a page. In a future ES6 with a future DOM where NodeList extends
Array, will `ids` no longer hold an array of strings but try to
remain a NodeList?

There's a good chance this will break some of my code. I'm capable
of changing my code and writing this to be more future-friendly from
now on (I'm not one who prefers backwards compatibility over a
better language). But I would have always assumed I was doing things
correctly before, and I'm curious if the rest of the internet will
be okay..?


Since you're using Array.prototype.map there, your code will indeed give
you an array of string IDs, as it always did.


No it won't. In the current proposal (which I'd like to change, I think 
Array is better default container for map), if NodeList would subclass 
Array, applying (generic) Array.prototype.map on instance of NodeList 
would create a new NodeList and would try to put ids on there.


Herby


Rick


Nathan

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