Le 29/12/2013 14:42, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 29/12/2013 01:48, Brendan Eich a écrit :
>>> David Bruant wrote:
>>>> it's somewhat ironic that Array carries 'from' given it's the only 
>>>> "class" that doesn't need it per case study for 3) above :-)
>>>
>>> But Array is the return type.
>> It's always the return type of Array.from(x), but not the return type 
>> of Array.from.call(Whatever, x).
>
> Of course, but why is this a problem for the name? Collection.from for 
> Collection extends Array carries the same connotation.
>
> Let's stick to real problems! The name is not a problem, AFAICT.
The part you answered to was a sidenote in my original message :-/ I 
never meant to question the name.

Back to the real problem.
As a summary, Rick explained that the problem to solve was ES6 code 
using ES3/5 codebases and the need to easily turn the arraylikes the 
latter define to real iterable for use in the former.
It is an author's problem today. By that I mean that it's not a language 
expressivity problem (like the one WeakMap, Proxies or Symbols solve) 
and it is a temporary problem (granted, the transition period may last 
10 years, but it's still temporary).

I believe this problem should be solved by authors via libraries and/or 
tooling and that the language should not carry a scar of a transitional 
problem. As a matter of fact, the library to solve the transitional 
problem is 20 (!) straightforward lines of code and already exists [1] 
(and with Rick's blessing, it'll be open source), so I don't believe 
assistance from the language is needed.

The costs of supporting arraylikes aren't big (zero in runtime?) though. 
Eventually, this part will just be dead code. Not optimal, but not a big 
deal.

Ok, thanks everyone :-)

David

[1] https://gist.github.com/rwaldron/1074126#file-array-goodies-js-L15-L36

Le 29/12/2013 14:42, Brendan Eich a écrit :
> Of course, but why is this a problem for the name? `Collection.from` for 
> `Collection extends Array` carries the same connotation.
>
> Let's stick to real problems! The name is not a problem, AFAICT.

The part you answered to was a sidenote in my original message :-/ I 
never meant to question the name.

Back to the real problem.
As a summary, Rick explained that the problem to solve was ES6 code 
using ES3/5 codebases and the need to easily turn the arraylikes the 
latter define to real iterable for use in the former.
It is an author's problem today. By that I mean that it's not a language 
expressivity problem (like the one WeakMap, Proxies or Symbols solve) 
and it is a temporary problem (granted, the transition period may last 
10 years, but it's still temporary).

I believe this problem should be solved by authors via libraries and/or 
tooling and that the language should not carry a scar of a transitional 
problem. As a matter of fact, the library to solve the transitional 
problem is 20 (!) straightforward lines of code and already exists [1] 
(and with Rick's blessing, it'll be open source), so I don't believe 
assistance from the language is needed.

The costs of supporting arraylikes aren't big (zero in runtime?) though. 
Eventually, this part will just be dead code. Not optimal, but not a big 
deal.

[1]: https://gist.github.com/rwaldron/1074126#file