Oops, you're right in these cases. The CheckIterable spec helper seems
over-general. Allen?
/be
Gary Guo wrote:
Date: Mon, 22 Dec 2014 21:28:54 -0800
From: bren...@mozilla.org
Your suggestion breaks Array.from and TypedArrayFrom.
In the spec:
8. Let arrayLike be ToObject(items).
A
From: curvedm...@gmail.com
Date: Tue, 23 Dec 2014 14:55:57 +0800
Given an array of [1,2,3] and other array of [“a”,”b”], it should return
[1,”a”,2,“b”,3]. (probably a lot of edge cases to cover, but just ignore them
for now).
It is not a hard task. I don't think we need to add it into the
From: curvedm...@gmail.com
Date: Tue, 23 Dec 2014 14:55:57 +0800
Given an array of [1,2,3] and other array of [“a”,”b”], it should return
[1,”a”,2,“b”,3]. (probably a lot of edge cases to cover, but just ignore them
for now).
I came up with an idea. Symmetric to String.raw, we can have a
Thanks for the suggestion.
You inspired me to realize that the basic idea shouldn’t be to find a way to
intersperse two arrays, but to find a way to undo the tagging of template.
so `template` === tag`template`, where tag = (templateObj, …args) =
untag(templateObj, …args)
If you intend to put
Since the target (templateObj) is an array, I think the method should belong
to Array, and it should behave like a join, but instead of joining array
items with a string, it joins with many strings. Maybe something like
Array.prototype.interspersedJoin (much like your String.default):
Open questions:
* how to fallback? ideally, we will need a way to detect modules support,
equivalent to noscript in semantic.
Is there much interest in a fallback option? I would think that the
typical web shop would have little to no interest in dual-delivering both
proper modules and
actually, in my working copy of the spec, CheckIterable has already been
updated to look like:
1. If obj is undefined or null, then return undefined.
2. Return GetV(obj, @@iterator).
where GetV is similar to Get but it boxes non-object values before doing the
property
Perhaps the most elegant way is functional composition on arrays, not
string hacking just-so imperative coding: zip composed with flatten and
join. You could even use underscore.js:
http://underscorejs.org/#flatten
http://underscorejs.org/#zip
but JS's OO standard library style prefers method
Dear Santa,
I wish since ES3 era that properties defined on a prototype are by
default **not** enumerable.
By any chance we can make this happen in ES6 classes?
Or better ... why would anyone expect or want them to be enumerable?
To define a `class` is a very explicit intent, I believe having
On 12/23/14 4:35 PM, Andrea Giammarchi wrote:
Or better ... why would anyone expect or want them to be enumerable?
This is a good question. Note that there is web content that depends on
the current setup wherein stuff on DOM prototypes is enumerable... you
may want to check on why exactly
For ES6 you could use http://github.com/rbuckton/QueryJS like this:
```
var a = [1,2,3];
var b = [a, b, c]
var c = Query
.from(a)
.zip(b, (a, b) = [a, b])
.flatMap(a = a)
.toArray()
.join();
```
Ron
Sent from my Windows Phone
From: Brendan
On Tue Dec 23 2014 at 7:35:44 PM Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Dear Santa,
I wish since ES3 era that properties defined on a prototype are by
default **not** enumerable.
By any chance we can make this happen in ES6 classes?
ES6 is done, properties of user created
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args) {
return String.raw({raw: templateObj}, …args);
}
On Dec 24, 2014, at 7:39 AM, Brendan Eich bren...@mozilla.org wrote:
Perhaps the most elegant way is functional composition on arrays, not
There was some heated debate on twitter too just yesterday:
https://twitter.com/domenic/status/547146484479561730
https://twitter.com/domenic/status/547146484479561730
Just wondering, is es6 class frozen? In those tweets Brendan proposed enum in
obj lit, not in class”. Looks like class is still
It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong. OTOH the bar for any
change, including what is regarded by many (but not all) as a fix, is
very high.
We should take advantage of es-discuss to debate the crucial question,
I would say enumerate through classes' or instances' properties are a strange
use and should be discouraged. I would prefer nothing but instance properties
to be enumerable. To me, it is illogical for methods to be enumerable.
In all the discussions I've observed, the primary argument for
enumerability has been consistency with ES5 prototype conventions. I don't
think I've seen a single argument in favor, though, based on the actual
intrinsic merits of that behaviour.
So, do such arguments exist?
On Dec 23, 2014 11:26
Clever -- treat the cooked values as raw. Should work -- test in Traceur?
/be
Glen Huang wrote:
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args) {
return String.raw({raw: templateObj}, …args);
}
Jeremy Martin wrote:
In all the discussions I've observed, the primary argument for
enumerability has been consistency with ES5 prototype conventions. I
don't think I've seen a single argument in favor, though, based on the
actual intrinsic merits of that behaviour.
Right, hence my tweet
This returns true in traceur:
```js
function tag(templateObj, ...args) {
return String.raw({raw: templateObj}, ...args);
}
let content = world;
console.log(tag`hello\n${content}` === `hello\n${content}`);
```
Looks like problem solved. :)
On Dec 24, 2014, at 12:44 PM, Brendan Eich
The question is: what should ES6 classes choose as the default? What's the
most useful default, independent of various backward-looking consistencies?
What, if the future is bigger than the past, would be best?
Framed that way, then non-enumerability.
If we want to preserve any kind of
On Wednesday, December 24, 2014, Kevin Smith zenpars...@gmail.com wrote:
The question is: what should ES6 classes choose as the default? What's the
most useful default, independent of various backward-looking consistencies?
What, if the future is bigger than the past, would be best?
Framed
I'll just throw out mixins as a possible reason to keep enumerability.
I don't think enumerability really bears on mixins in ES6, because (for
one) the mixin source could have symbol-named properties. A fully-featured
mixin function will need to use Object.getOwnPropertySymbols, etc.
Actually mixins shouldn’t be done with Object.assign if that’s what you mean.
I think the language should provide a syntax for that (e.g., Lightweight traits
on http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/)
Although I guess it’s not very easy to desugar to es5 if there is no way to
enumerate prototype methods/properties. (probably impossible?)
On Dec 24, 2014, at 1:17 PM, Glen Huang curvedm...@gmail.com wrote:
Actually mixins shouldn’t be done with Object.assign if that’s what you mean.
I
Object.defineProperty could easily do that.
From: curvedm...@gmail.com
Date: Wed, 24 Dec 2014 13:33:24 +0800
Although I guess it’s not very easy to desugar to es5 if there is no way to
enumerate prototype methods/properties. (probably impossible?)
How?
Given that you don’t know the names of the prototype properties and methods
contained (could be deep in the prototype chain) in a object. How do you add
these to another object?
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily do
I guess it’s probably a misunderstanding.
I was saying that a feature like lightweight traits is probably impossible to
desugar to es5, if class syntax makes properties and methods non-enum.
On Dec 24, 2014, at 1:50 PM, Gary Guo nbdd0...@hotmail.com wrote:
Object.defineProperty could easily
Given that you don’t know the names of the prototype properties and
methods contained (could be deep in the prototype chain) in a object. How
do you add these to another object?
getOwnPropertyNames, getOwnPropertySymbols, and getPrototypeOf to traverse
the prototype chain.
Oh, forget about those. Thanks. Then problem solved.
non-enum class syntax + trait syntax. This could make prototypal inheritance a
joy to write. :)
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
Given that you don’t know the names of the prototype properties and
Although when desugaring to es5, no need to consider symbol properties.
On Dec 24, 2014, at 2:02 PM, Kevin Smith zenpars...@gmail.com wrote:
getPrototypeOf
___
es-discuss mailing list
es-discuss@mozilla.org
On 12/23/14 8:49 PM, Brendan Eich wrote:
On the DOM quirks point
Here's the thing. Ignoring for the moment the classes situation, it
seems to me that for DOM stuff specifically we have three options:
1) Have all DOM prototype stuff be enumerable. This leaves us in a
Conway's Law
32 matches
Mail list logo
