Re: Overly complicated Array.from?
Le 27/12/2013 19:10, Claude Pache a écrit :
There is still the issue of potential libraries that produce
arraylikes that don't inherit from a built-in arraylike prototype:
those won't benefit from your polyfill without changing their
inheritance strategy.
I don't understand the expression inherit from a built-in arraylike
prototype. Could you explain this further?
(I don't know whether it's a common issue.)
I think any use case involving libraries can be solved.
In an ES6 world, a library would make Array.from work via setting an
appropriate @@iterator on the objects it generates.
Based on what I suggested (internalize iterators in Array.from code for
polyfills), the ES5 equivalent is to override Array.from as such:
js
(function(){
var nativeArrayFrom = Array.from;
Array.from = function(x){
if(/*x is of my library type*/){
/* generate an equivalent array using the traversal logic
that would be used for its @@iterator in ES6
*/
}
else{
return nativeArrayFrom(x);
}
}
})()
Granted, it's not super elegant solution, but it does work. The overhead
becomes significant only in the degenerate cases where dozens of
libraries override Array.from.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should the default constructor return the return value of super?
On Fri, Dec 27, 2013 at 10:22 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 27, 2013, at 7:27 AM, Brendan Eich wrote:
...
I thought Allen designed things so
class C {}
differed from
class C extends Object {}
so as in the first case to avoid (a) super calling Object and making a
useless newborn; (b) C inheriting class-side properties from Object.
Exactly, see step 7 of
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation
Allen
I think the differences should include to making calls to super() illegal
when 'extends' is absent:
class C { constructor(url) {super(url);}} // legal, I expected illegal.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
Le 28/12/2013 15:25, Brendan Eich a écrit :
This seems overcomplicated. Isn't the likelier code something like
Array.from || (Array.from = function(b) { var a=[]; for (var i=0;
ib.length; i++) a.push(b[i]); return a; });
Isn't the whole point to impute arraylikeness to the parameter?
In any case the important point is that it's possible to implement in an
ES5 env whatever behavior is expected from Array.from in an ES6 env.
Granted, it's not super elegant solution, but it does work. The
overhead becomes significant only in the degenerate cases where
dozens of libraries override Array.from.
David, I took your side in the TC39 meeting, as the meeting notes
disclosed. Rick prevailed (I think, my memory is hazy).
It's what I read from the notes too, but I feel something may have been
overlooked.
You want the polyfillers to pay the price, while Rick proposes that
ES6's built-in absorb arraylike fallback handling.
The difference is not in the polyfill (old browser) case, but in the
present and future (ES6 and above) cases: some objects will remain
arraylike yet lack @@iterator.
In ES6 and above, why would one create such an object? What's a good use
case?
My understanding of the current consensus is that an arraylike without
@@iterator wouldn't work for for-of loops nor spread. Why not just
create an array? jQuery and Zepto want to subclass Array (one creates
arraylike, the other does subclass setting __proto__). It wasn't
possible in ES5, but is in ES6 with classes (and the super+@@create
infrastructure).
I feel that all the cases that justified arraylikes in the past have
much better alternatives in ES6.
My little experience building a Firefox addon even suggests that sets
replace arrays in most situations as most of what I do with arrays is
.push, for-of and .map/filter/reduce (by the way, Set.prototype needs
these too, but another topic for another time).
Why shouldn't Array.from help them out?
If these objects have a good reason to exist in an ES6 and above world,
I agree, that's a good point. But is there a use case justifying their
existence?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should the default constructor return the return value of super?
On Dec 28, 2013, at 5:35 AM, Sebastian Markbåge wrote:
I completely agree that is the intended use and what we should be encouraging
people to do. What I'm asking for is to intentionally break best-practices
for a specialized use case.
The use case I had in mind was React components. Components in React are
described as classes which makes them seem approachable to a broad user base.
They cannot and should not be accessed as class instances though. The
instances are immutable data structures used exclusively by the library. The
base constructor could look something like this:
constructor(x) {
return { _hiddenInstance: this, _instantiationContext: CurrentContext, _id:
uid(), _someArgument: x };
}
This would generate a descriptor that can be used by the library but only
used as a reference by the user. This allows users to declare classes just
like they're used to and even instantiate them normally. However, they'd only
be given access to the real instance at the discretion of the library.
With the current ES6 spec. you can accomplish the same thing via:
static [Symbol.create]() {
return {
_hiddenInstance: super(), //this will create the normal instance
_instantiationContext: CurrentContext,
_id: uid()
} //this is the object that is passed as the 'this' value to the
constructor
};
constructor(x) {
this._someArgument = x
}
Of course, we could have all users wrap their classes in some kind of
decorator constructor and that's probably where we'll end up for clarity.
It's would've been a neat pattern though.
Regarding adding 'return' to the default constructor body. It appears that
technically it would be a benign change. However, the only reason to do so
would be accommodate superclasses that deviate from the above patterns. In
that case, you are probably already in the weeds. I'm not sure that we
should be trying to facilitate such deviations.
It seems to me that whether we add it or not is arbitrary. By not adding it
we're intentionally removing this use case (forever). IMO we need to have a
reason to intentionally prevent a use case if it could be easily supported.
I'd buy almost any argument here except that it's in bad taste to use this
pattern.
If we have reason to believe that this pattern will be harmful, do we also
have to do more to prevent normal constructors from returning anything other
than this?
I'm not exactly sure where who you see ES6 classes fitting into React. Whether
you are talking about using them at the meta level to implement React or
whether you want to replace React.createClass with something like:
class MyComponent extends React.Component {
render() { ... }
}
The code I gave above should work in the latter case (although I suspect you
are really doing something more complex with the constructor argument).
However, to create an instance you would have to say
new MyComponent({})
instead of
MyComponent({})
So this makes me think that you may have a different integration in mind.
Perhaps:
let MyComponent = React.create(class {...});
I think the topic of who ES6 class definitions (and other features) integrate
with frameworks that provide their own abstraction mechanism is an important
one so it would be good to explore this further in the context of React.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
On Sat, Dec 28, 2013 at 11:37 AM, David Bruant bruan...@gmail.com wrote:
Le 28/12/2013 15:25, Brendan Eich a écrit :
This seems overcomplicated. Isn't the likelier code something like
Array.from || (Array.from = function(b) { var a=[]; for (var i=0;
ib.length; i++) a.push(b[i]); return a; });
Isn't the whole point to impute arraylikeness to the parameter?
In any case the important point is that it's possible to implement in an
ES5 env whatever behavior is expected from Array.from in an ES6 env.
Granted, it's not super elegant solution, but it does work. The overhead
becomes significant only in the degenerate cases where dozens of libraries
override Array.from.
David, I took your side in the TC39 meeting, as the meeting notes
disclosed. Rick prevailed (I think, my memory is hazy).
It's what I read from the notes too, but I feel something may have been
overlooked.
You want the polyfillers to pay the price, while Rick proposes that ES6's
built-in absorb arraylike fallback handling.
The difference is not in the polyfill (old browser) case, but in the
present and future (ES6 and above) cases: some objects will remain
arraylike yet lack @@iterator.
In ES6 and above, why would one create such an object? What's a good use
case?
My understanding of the current consensus is that an arraylike without
@@iterator wouldn't work for for-of loops nor spread. Why not just create
an array? jQuery and Zepto want to subclass Array (one creates arraylike,
the other does subclass setting __proto__). It wasn't possible in ES5, but
is in ES6 with classes (and the super+@@create infrastructure).
jQuery is a bad example to use in this case, because it will _never_
include features that can't be made to work consistently across all
platforms that are supported. This includes jQuery 2.x, which has no less
and no more features or capabilities than jQuery 1.x (and never will).
I feel that all the cases that justified arraylikes in the past have much
better alternatives in ES6.
My little experience building a Firefox addon even suggests that sets
replace arrays in most situations as most of what I do with arrays is
.push, for-of and .map/filter/reduce (by the way, Set.prototype needs these
too, but another topic for another time).
Realistically, this is a minority use case. The most common use case is a
web-based application that often must work on platforms as old as IE8, and
that shouldn't _limit_ the progress and evolution in ES6 features.
Why shouldn't Array.from help them out?
If these objects have a good reason to exist in an ES6 and above world, I
agree, that's a good point. But is there a use case justifying their
existence?
In the ES6 world, there will be userland and platform objects that can't be
upgraded to real iterables, eg. application code that must behave correctly
on platforms with and without @@iterator (ie. browsers that have large
market share but don't auto-update). Array.from can be shimmed such that
code like the following will work correctly on both older ES3-5
(Array.prototype methods shimmed for ES3) or ES6 platforms:
if (typeof Array.from === undefined) {
...shim it.
}
function f() {
// Works correctly on browsers that have implemented @@iterator on
arguments objects
// as well as those that have not.
return Array.from(arguments).map(...);
}
// Or...
// Works correctly on browsers that have implemented @@iterator on
NodeList objects
// as well as those that have not.
Array.from(qSA(.selector)).forEach(...);
`for-of` won't even exist on these older platforms, but for code that only
needs to run on ES6 platforms, Array.from provides a spread or make
iterable mechanism for those objects that _can't_ be upgraded (for any
reason, as noted above):
// Turn a jQuery object into an iterable:
Array.from(jQuery(.selector));
(This can't be done with spread)
Array.from bridges the gap between ES3/5 and ES6 while remaining useful in
an ES6 and post ES6 world by providing an assimilation path for objects
that have pre-existing constraints.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should the default constructor return the return value of super?
Allen Wirfs-Brock wrote:
I generally try to avoid early errors that have a lot of conditions
associated with them.
That's a warning sign in JS specs, indeed.
Adding class syntax as (mostly) sugar for the prototypal pattern does
not obviously mean rejecting all unusual or exceptional variants
possible in the prototypal pattern. I say let super be used even in
class C{}'s constructor, and let return-from-constructor work without
requiring [Symbol.create]. JS is dynamic.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
On Saturday, December 28, 2013, Domenic Denicola wrote:
Why can't jQuery do
```js
if (typeof Symbol !== undefined Symbol.iterator) {
jQuery.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator];
}
```
For the same reason I've stated here any time anyone ever brings up
anything anything jQuery might do: jQuery doesn't ship anything in core
that cannot be made to work consistently in all browsers that both 1.x and
2.x are expected to support. Additionally, jQuery has never and will never
ship conditional features in the core library.
Rick
--
From: Rick Waldron javascript:_e({}, 'cvml', 'waldron.r...@gmail.com');
Sent: 12/28/2013 14:24
To: David Bruant javascript:_e({}, 'cvml', 'bruan...@gmail.com');
Cc: Brendan Eich javascript:_e({}, 'cvml', 'bren...@mozilla.com');;
EcmaScript javascript:_e({}, 'cvml', 'es-discuss@mozilla.org');
Subject: Re: Overly complicated Array.from?
On Sat, Dec 28, 2013 at 11:37 AM, David Bruant bruan...@gmail.com wrote:
Le 28/12/2013 15:25, Brendan Eich a écrit :
This seems overcomplicated. Isn't the likelier code something like
Array.from || (Array.from = function(b) { var a=[]; for (var i=0;
ib.length; i++) a.push(b[i]); return a; });
Isn't the whole point to impute arraylikeness to the parameter?
In any case the important point is that it's possible to implement in an
ES5 env whatever behavior is expected from Array.from in an ES6 env.
Granted, it's not super elegant solution, but it does work. The overhead
becomes significant only in the degenerate cases where dozens of libraries
override Array.from.
David, I took your side in the TC39 meeting, as the meeting notes
disclosed. Rick prevailed (I think, my memory is hazy).
It's what I read from the notes too, but I feel something may have been
overlooked.
You want the polyfillers to pay the price, while Rick proposes that ES6's
built-in absorb arraylike fallback handling.
The difference is not in the polyfill (old browser) case, but in the
present and future (ES6 and above) cases: some objects will remain
arraylike yet lack @@iterator.
In ES6 and above, why would one create such an object? What's a good use
case?
My understanding of the current consensus is that an arraylike without
@@iterator wouldn't work for for-of loops nor spread. Why not just create
an array? jQuery and Zepto want to subclass Array (one creates arraylike,
the other does subclass setting __proto__). It wasn't possible in ES5, but
is in ES6 with classes (and the super+@@create infrastructure).
jQuery is a bad example to use in this case, because it will _never_
include features that can't be made to work consistently across all
platforms that are supported. This includes jQuery 2.x, which has no less
and no more features or capabilities than jQuery 1.x (and never will).
I feel that all the cases that justified arraylikes in the past have much
better alternatives in ES6.
My little experience building a Firefox addon even suggests that sets
replace arrays in most situations as most of what I do with arrays is
.push, for-of and .map/filter/reduce (by the way, Set.prototype needs these
too, but another topic for another time).
Realistically, this is a minority use case. The most common use case is
a web-based application that often must work on platforms as old as IE8,
and that shouldn't _limit_ the progress and evolution in ES6 features.
Why shouldn't Array.from help them out?
If these objects have a good reason to exist in an ES6 and above world, I
agree, that's a good point. But is there a use case justifying their
existence?
In the ES6 world, there will be userland and platform objects that can't
be upgraded to real iterables, eg. application code that must behave
correctly on platforms with and without @@iterator (ie. browsers that have
large market share but don't auto-update). Array.from can be shimmed such
that code like the following will work cor
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Overly complicated Array.from?
I believe that Array.from's only purpose is to provide guidance for polyfills for people to use in ES3/ES5 code; nobody writing ES6 would ever use it. In essence it's saying TC39 likes es6-shim more than Underscore, and is helping tell them what should be in it, with the hope that people use it. At least, that's what it seems to me. From: David Bruantmailto:bruan...@gmail.com Sent: 12/28/2013 17:28 To: Rick Waldronmailto:waldron.r...@gmail.com Cc: Brendan Eichmailto:bren...@mozilla.com; EcmaScriptmailto:es-discuss@mozilla.org Subject: Re: Overly complicated Array.from? Le 28/12/2013 20:24, Rick Waldron a écrit : On Sat, Dec 28, 2013 at 11:37 AM, David Bruant bruan...@gmail.commailto:bruan...@gmail.com wrote: I feel that all the cases that justified arraylikes in the past have much better alternatives in ES6. My little experience building a Firefox addon even suggests that sets replace arrays in most situations as most of what I do with arrays is .push, for-of and .map/filter/reduce (by the way, Set.prototype needs these too, but another topic for another time). Realistically, this is a minority use case. Agreed. I was just trying to share what I felt the future taste like. The most common use case is a web-based application that often must work on platforms as old as IE8, and that shouldn't _limit_ the progress and evolution in ES6 features. Ok, I think I better understand what you meant by can't be iterable. Why shouldn't Array.from help them out? If these objects have a good reason to exist in an ES6 and above world, I agree, that's a good point. But is there a use case justifying their existence? In the ES6 world, there will be userland and platform objects that can't be upgraded to real iterables, eg. application code that must behave correctly on platforms with and without @@iterator Ok for userland objects, but do you have examples for platform objects? I feel that it's up to the W3C folks to add appropriate @@iterators to the objects they define... and it's already the case with indexed getters for instance [1]. (Firefox has already implemented it, you can for-of the result of qSA \o/). I wonder what you mean by behave correctly on platforms with and without @@iterator. If you're targetting both types of platforms, you can't use the new facilities (for-of and spread), so you don't need for your objects to adhere to the iterable protocol. (ie. browsers that have large market share but don't auto-update). I already see IE10 market share being higher than IE9. IE8 might be the last browser without symbols `for-of` won't even exist on these older platforms, but for code that only needs to run on ES6 platforms, Array.from provides a spread or make iterable mechanism for those objects that _can't_ be upgraded (for any reason, as noted above): // Turn a jQuery object into an iterable: Array.from(jQuery(.selector)); (This can't be done with spread) Why can't the code that only run in ES6 provide its own make iterable facility? As you said, it's polyfillable. I think spread is even compile-to-ES3-able. Array.from bridges the gap between ES3/5 and ES6 while remaining useful in an ES6 and post ES6 world by providing an assimilation path for objects that have pre-existing constraints. What you're indirectly saying here is that Array.from is not useful in an ES6-only code base (since @@iterator+spread can be used). Libraries (Array._from?) and tooling (compile spread to ES3) can be enough for the transition, no? David [1] http://heycam.github.io/webidl/#es-iterators ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
On Sat, Dec 28, 2013 at 5:44 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I believe that Array.from's only purpose is to provide guidance for polyfills for people to use in ES3/ES5 code; nobody writing ES6 would ever use it. Ignoring any of the previous benefits I've discussed, it seems you're forgetting about the map function feature of Array.from? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Overly complicated Array.from?
Yes, I am; many apologies. I also forgot about how it would be useful for subclasses, e.g. Elements.from(nodeList), since subclasses don't have their own dedicated spread syntax. Withdrawn in full. From: Rick Waldronmailto:waldron.r...@gmail.com Sent: 12/28/2013 18:12 To: Domenic Denicolamailto:dome...@domenicdenicola.com Cc: David Bruantmailto:bruan...@gmail.com; Brendan Eichmailto:bren...@mozilla.com; EcmaScriptmailto:es-discuss@mozilla.org Subject: Re: Overly complicated Array.from? On Sat, Dec 28, 2013 at 5:44 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: I believe that Array.from's only purpose is to provide guidance for polyfills for people to use in ES3/ES5 code; nobody writing ES6 would ever use it. Ignoring any of the previous benefits I've discussed, it seems you're forgetting about the map function feature of Array.from? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Should the default constructor return the return value of super?
On Sat, Dec 28, 2013 at 8:35 AM, Sebastian Markbåge
sebast...@calyptus.eujavascript:_e({}, 'cvml',
'sebast...@calyptus.eu');
wrote:
I completely agree that is the intended use and what we should be
encouraging people to do. What I'm asking for is to intentionally break
best-practices for a specialized use case.
The use case I had in mind was React components. Components in React are
described as classes which makes them seem approachable to a broad user
base. They cannot and should not be accessed as class instances though. The
instances are immutable data structures used exclusively by the library.
The base constructor could look something like this:
constructor(x) {
return { _hiddenInstance: this, _instantiationContext: CurrentContext,
_id: uid(), _someArgument: x };
}
This would generate a descriptor that can be used by the library but only
used as a reference by the user. This allows users to declare classes just
like they're used to and even instantiate them normally. However, they'd
only be given access to the real instance at the discretion of the library.
We're doing this with Maps (for non-DOM bound data) and WeakMaps (for DOM
bound data) in the FirefoxOS Messages app (for Recipients, Threads and
Draft data objects).
Rick
Of course, we could have all users wrap their classes in some kind of
decorator constructor and that's probably where we'll end up for clarity.
It's would've been a neat pattern though.
Regarding adding 'return' to the default constructor body. It appears
that technically it would be a benign change. However, the only reason to
do so would be accommodate superclasses that deviate from the above
patterns. In that case, you are probably already in the weeds. I'm not
sure that we should be trying to facilitate such deviations.
It seems to me that whether we add it or not is arbitrary. By not adding
it we're intentionally removing this use case (forever). IMO we need to
have a reason to intentionally prevent a use case if it could be easily
supported. I'd buy almost any argument here except that it's in bad taste
to use this pattern.
If we have reason to believe that this pattern will be harmful, do we also
have to do more to prevent normal constructors from returning anything
other than this?
___
es-discuss mailing list
es-discuss@mozilla.org javascript:_e({}, 'cvml',
'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: Overly complicated Array.from?
Le 29/12/2013 00:11, Rick Waldron a écrit : On Sat, Dec 28, 2013 at 5:44 PM, Domenic Denicola dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote: I believe that Array.from's only purpose is to provide guidance for polyfills for people to use in ES3/ES5 code; nobody writing ES6 would ever use it. Ignoring any of the previous benefits I've discussed, it seems you're forgetting about the map function feature of Array.from? Ok, so to re-focus for those following at home, there are 3 cases to consider for authors: 1) code only aiming at ES3/5 2) code aiming at both ES3/5 and ES6 environments 3) code only aiming at ES6 envs. For 1), let's all keep doing what we've been doing. In ES3/5, there is not really a notion of iterable protocol as it's not used by the language as it is in ES6. For 3), from an iterable to an array, it takes ``[...iterable]`` IIUC, no need for Array.from at all. 2) is the subtle case. There is only one code base. Because it needs to work in ES3/5, it can't use @@iterable (like jQuery as Rick stated). However, ES6 code may want to iterate over the arraylikes generated by the library with for-of and spread. This is where Array.from comes handy if it works both for @@iterables and arraylikes. But an Array._from library could work equally well for this purpose. No need for the built-in Array.from to handle arraylikes. Dominic Denicola: I also forgot about how it would be useful for subclasses, e.g. Elements.from(nodeList), since subclasses don't have their own dedicated spread syntax. Withdrawn in full. Oh... super true. Array.from or perhaps less confusingly just-from enables to convert any iterable to another iterable (assuming proper @@create setup). But that's an ES6-only use case and is unrelated to the arraylike handling I think. Side note: 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 :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
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). I called Array.from just-from in my previous message as an attempt to reduce the confusion. In the latest draft, step 1 of Array.from is Let C be the this value. There are different return points that all return 'A' and 'A' created at step 8.a.i as the result of C.[[Construct]]. And C.[[Construct]] doesn't have to return an Array. That's at least my understanding of the current draft. just-from is a function that turns the iterable passed as argument to an array-like. It'll be an Array for Array.from but whetever else for Whatever.from. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should the default constructor return the return value of super?
I'm not exactly sure where who you see ES6 classes fitting into React.
We've explored using:
class MyComponent extends React.Component { };
let MyComponent = React.createClass(class { });
let MyComponent = React.createClass({ method() { super(); } });
Your @@create example convinced me that we're better off using the first
one together with @@create. That will allow us to delay allocation of the
hidden instance.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
