On 4/2/2014 8:01 AM, Andreas Rossberg wrote:
That is very helpful, thanks! I agree with a lot with what you say.
But to expand on my reply to your blog post, I have one fundamental
concern: I think the idea that value types should be objects would
require stretching the notion of object too far,
On 3/14/2014 5:16 PM, Mark Volkmann wrote:
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
Further rational:
* Symmetry with defineProperty/defineProperties.
* One of the benefits of defineProperties (and create) is that they handle
errors such that the failure of any individual property doesn't necessarily
fail all the remaining ones. It is, of course, possible for a developer to
On 2/21/2014 3:08 PM, Allen Wirfs-Brock wrote:
It might be worth coming up with good terms for ES5-style optional
arguments and ES6-style optional arguments which can be used
consistently in the spec. They can already be distinguished by
signature, ie:
```js
Array.prototype.reduce (
What you're probably seeing is that the wiki no longer has up to date
information. As things have been fully fleshed out in the es6 draft spec, the
wiki is no longer up to date.
To answer your question, the iterator protocol hasn't changed back to using
StopIteration. It's still { value, done
On 2/11/2014 11:04 AM, Allen Wirfs-Brock wrote:
I can't find any explicit mention of this in the meeting notes [1]
where we decided to make Symbol a primitive type with a wrapper class.
However, I made the appropriate changes to the spec. immediately
after that meeting when the discussion
On 2/3/2014 10:22 AM, Claude Pache wrote:
Therefore, it would be nice if `return expression` would be statically
forbidden in the `constructor` method when defined using the `class` syntax
(but a bare `return` is fine, which slightly complicates the grammar).
I like the motivation, but doing
On 1/23/2014 4:46 PM, Domenic Denicola wrote:
Task.js is still on JavaScript 1.8, and is not ES6-compatible. It won't work
with modern browsers, or with Regenerator.
For most uses, Task.js's Task.spawn can be replaced with a smaller
helper function:
```js
function spawn(thunk) {
return
The implementations of Maps and Sets in the wild that I am aware of
(IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue
as comparator while the spec calls for SameValueZero. It seems like
either the implementations need to update (quickly) to match the spec.
before too much
On 1/8/2014 1:05 PM, Andrea Giammarchi wrote:
Sorry, I explained it badly ... let me try again:
what if a DOM event handler uses/creates/invokes inside its function
body a generator?
Will the event pause until this will be satisfied?
`a.addEventListener('click', function(e){
How about Maps? And since their order is deterministic, how about the rest of
the array extras?
On Dec 31, 2013, at 11:36 AM, David Bruant bruan...@gmail.com wrote:
Hi,
I've been playing with Sets recently and believe that the following additions
would make them more useful by default:
On 12/3/2013 11:29 AM, Allen Wirfs-Brock wrote:
I don't have the time right now, but as a rough approximation take the
most recent specification of MixinProperties (which is the guts of
Object.mixin)
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-mixinproperties
On 12/3/2013 10:28 PM, Andrea Giammarchi wrote:
What if they never needed to do that since everything was workign
already as meant?
They can continue ignoring the new things from ES6 and nothing will break.
___
es-discuss mailing list
On Nov 15, 2013, at 5:54 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
On 15 Nov 2013, at 08:47, Kevin Smith zenpars...@gmail.com wrote:
From the examples I've seen so far in this discussion, it's likely that what
is wanted isn't generator arrows, as much as syntactic support
Currently, it's not allowed that arrow functions be generators. I did a
bit of searching and couldn't find the original reasoning behind this.
`*() = {}` doesn't seem to be a problematic grammar since `foo * () =
{}` isn't valid. The problem I do see is the mismatch between the
generator class
On 11/11/2013 11:31 AM, Corey Frang wrote:
I hate to bring this up, as I'm sure I've missed a bunch of the
arguments that define WHY, but if this is the case, it seems
unintuitive to me that passing undefined still results in a default
param being set.
function test(a = 1) { console.log(a);
On 11/1/2013 1:28 PM, James Burke wrote:
Perhaps you know how a mutable slot could be expressed using existing
syntax for creating Module objects? Illustrating how would clear up a
big disconnect for me.
If I'm understanding what you mean by mutable slot, the only way it
can be expressed
On 11/1/2013 4:29 PM, Mark S. Miller wrote:
Hi Allen, perhaps I misunderstood. But I thought that as of ES6,
O.p.toString can't be used for reliable brand checking of anything,
including legacy ES=5 built-ins. Not so? How would I do such a check
of a legacy built-in in ES6?
In the spec for
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of Arguments, Array, Boolean, Date, Error,
Function, Number, RegExp, or String and SameValue(tag,
builtinTag) is false, then let tag be the string value ~
concatenated with the current value
On 11/1/2013 4:59 PM, Brandon Benvie wrote:
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of Arguments, Array, Boolean, Date, Error,
Function, Number, RegExp, or String and SameValue(tag,
builtinTag) is false, then let tag be the string
On 11/1/2013 7:13 PM, Allen Wirfs-Brock wrote:
Or we could simply not special case Proxy exotic objects and then Proxies would
be handled like any other object, the value of the objects @@toStringTag
property would be accessed and used to compose the toString result.
Which would result in
On 11/1/2013 8:54 PM, Allen Wirfs-Brock wrote:
This just reminds me how cold I still am on the fact that you can't easily
one-off Proxy anything that's not a plain Object, Array, or Function because of
the lack of an invoke trap and every other type of built-in has private
state... but I
On 10/31/2013 8:50 AM, David Bruant wrote:
I'm not sure it's worth making it work for jQuery. This is trying to
make a good use of same-origin multi-global which shouldn't exist in
the first place. Keeping same-origin access as it is and encouraging
people to add @sandbox even on same-origin
On 10/26/2013 7:44 AM, Michaël Rouges wrote:
Knowing that every function is an object, I am surprised that the
Object.create() method doesn't really allow cloning function.
Object.create creates Objects. You run into the same limitation when
trying to create Arrays with Object.create (doesn't
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote:
What your question does help me be more decisive on: We should not be in a rush
to add an Invoke, InvokeFunction, or any new traps not needed for membranes,
and not subject to a long history of examination. Invoke at least, as a derived
trap,
On 9/30/2013 4:41 AM, Domenic Denicola wrote:
I can't remember any discussion about Object(Symbol()). Why should it be
disallowed?
On the other hand, we agreed the other week on making 'new Symbol' and
Symbol.prototype.toString throw. That should address all likely accidents.
I only remember
V8 has currently implemented a name getter on Symbol.prototype that
returns the value passed to the Symbol function. In the latest spec
draft this is referred to as the [[Description]] field but there is no
way to access it. Is there intended to be something that allows
retrieving this?
On 9/30/2013 7:34 PM, Matthew Robb wrote:
var f = function(a=this){}
would transpile to something like:
var f = (function(){
function __funcHead__(){
a=this;
}
function __funcBody__(){
// do stuff
}
var a;
return function(a){__funcHead__.apply(this, arguments);return
On 9/30/2013 3:51 PM, Dmitry Soshnikov wrote:
Just re-read meeting notes, OK, cool on two scopes (seems like they
are not in the spec yet). Want to double-check though: whether it will
be possible to transpile now to ES3? From what I've seen in the notes,
the head-scope will be able to access
I'm actually now really curious what the following does:
```
function foo(x, y = (() = { arguments[0] = foo; return bar })()) {
return [x, y];
}
foo(5);
```
Arrow functions are not implicitly strict currently, right? If so, the
above should return `[foo, bar]`.
On 9/30/2013 8:57 PM, Brendan Eich wrote:
Easy: arguments is an early error in the body of an arrow.
Ok cool, that simplifies my previous examples a bit then. Instead of
using `call` and specifying the name of each argument, you can just use
`.apply(this, arguments)`.
On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote:
The newness was using using string literals+ concise methods to write
such meta=level methods.
What it brings to the table is that it address the meta stratification
issue in a reasonable manner without having to add anything (other
than the use
On 9/26/2013 7:18 PM, Adam Ahmed wrote:
Thanks, I see. The usage is for TaskResult sorts of things where the
scheduling is done via calls to `yield`, and the output of the
function is done via `return`. Fair enough. It still seems like a huge
footgun for the other cases which I'd expect are
On 9/25/2013 11:47 AM, Kevin Smith wrote:
How are namespaced strings inconvenient other than being a
non-identifier, or perhaps a longish identifier?
They are visible to enumeration.
___
es-discuss mailing list
es-discuss@mozilla.org
On 9/25/2013 12:20 PM, Rick Waldron wrote:
This list has been around the new pragma block several times and in
the end the following (or something similar) holds: adding a new
pragma will effectively creates a new version of the language and
that's not going to happen any time soon.
Indeed.
On 9/24/2013 11:38 AM, Brendan Eich wrote:
Based on all the great input (thanks to André for his summary, and
Mark for pointing out works always beats half-works/half-broken),
and talking to Allen 1:1, I'm back to status quo ante: we are better
off being conservative designers by deferring
On 9/20/2013 12:19 PM, Jason Orendorff wrote:
what's the justification for .hasOwn()?
a) allows more direct interception of Object.prototype.hasOwnProperty()
b) potentially less allocations each time someone calls .hasOwnProperty().
I think .hasOwn() should be removed.
Actually, taking the
On 9/20/2013 6:27 PM, Brandon Benvie wrote:
Actually, taking the precedent of removing getPropertyDescriptor,
it's has that would be removed. The implementation of [[Has]] can
easily walk the [[GetPrototype]] chain calling hasOwn on each until
true or [[GetPrototype]] returns null. In fact
On 9/16/2013 9:22 AM, Angus Croll wrote:
Thanks - I missed the obvious one I guess - though it still returns an
empty array in continuum and traceur.
At one point spread was to only work on indexed (array-like) objects.
Now it works on both indexed objects as well as iterables. This works in
On 9/12/2013 12:45 PM, Oliver Hunt wrote:
From talking to SpiderMonkey folk it sounds like SM nukes the |arguments|
identifier entirely if you use any of the new parameter logic (deconstruction,
defaults, or rest params). I would be happy with that.
This doesn't seem to be accurate, or I'm
On 9/6/2013 7:44 AM, Domenic Denicola wrote:
What does having these be generators buy us? I am almost sure I'm missing
something.
I don't think you're missing anything. They seem to be more accurately
described as Iterator Expressions than Generator Expressions. It might
be interesting if
The latest spec revision makes the function length property
configurable (section 8.3.16.6). Function.prototype.bind (15.3.3.5)
still produces functions with non-configurable length, however. I
think this may be an oversight, but I'm not sure.
___
Part of the function name proposal submitted would make name writable but not
configurable, which is the inverse of the current spec for length being
configurable but not writable. Seems there needs to be some discussion on what
attributes should be where.
On Aug 30, 2013, at 7:36 PM, Mark S.
compiling Objective-J into JS, to fix up every function's
name to tell its Obj-J pathname. But you wrote the name proposal -- you
should weigh in and even call this shot!
/be
Brandon Benvie mailto:bben...@mozilla.com
August 30, 2013 11:39 AM
Part of the function name proposal submitted would
On 8/22/2013 8:04 AM, Mark S. Miller wrote:
var Promise = (function(){
use strict; // of course
var brand = new WeakMap();
// only ever called with new
function HiddenPromiseConstructor(callback) {
// initialize this, which it can assume starts
On 8/19/2013 9:33 AM, Allen Wirfs-Brock wrote:
thisObj.[[Invoke]](propertyKey, function, argumentList)
This could allow [[Invoke]] to trap `call` and `apply`, if propertyKey
was allowed to be undefined.
___
es-discuss mailing list
On 8/16/2013 12:56 PM, Allen Wirfs-Brock wrote:
However, I think throwing is like to reveal bugs that might otherwise
be missed prior to deployment and as a code reader I would prefer to
encounter
let {x=undefined) = {};
which communicates much more clearly that there is an expectation that
On 8/16/2013 2:08 PM, Domenic Denicola wrote:
Actually, I think it'd be fantastic to have an easy way to communicate required
parameters in an options object.
I agree and this is why I was a fan of Axel's +/! this is required prefix.
One of the reason's JS is so popular is because hard
On 8/9/2013 3:36 PM, Axel Rauschmayer wrote:
let { +a: foo, b: bar } = { a: 1 }; // foo = 1, b = undefined
let { +a: foo, b: bar } = { }; // exception
function bla(+mandatoryArg, optionalArg1, optionalArg2 = 123) {
...
}
I presume these would also be valid, and do
On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
const MUST = () = {throw TypeError(Missing required parameter};
function foo (a=MUST(), b, c) {...}
But that doesn't work for:
```js
function foo({ a } = { a: MUST() }){}
foo({}); // doesn't throw
function bar({ +a }){}
bar({}); // would throw
On 8/9/2013 5:45 PM, Allen Wirfs-Brock wrote:
and if we make U+2639 a special token that evaluated to throw TypeError we
could say
function foo( {a=☹ }) {}
This would be awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to 'Object(x)
=== x'.
I was actually the original author of that code. =D The function was:
```js
function isObject(value){
let
On Aug 3, 2013, at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of the two existing commonly used tests for
'objectness' will continue to work correctly in the
On Aug 3, 2013, at 9:03 PM, Brandon Benvie bben...@mozilla.com wrote:
On Aug 3, 2013, at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of the two
On 8/2/2013 1:02 PM, Domenic Denicola wrote:
I know the answer will be obvious when I see it, but I can't quite
remember ... why is it important that `O[privateSymbol]` not invoke
the proxy?
That would leak the Symbol to the Proxy and then private Symbols
wouldn't carry a guarantee of
On 8/2/2013 1:15 PM, Domenic Denicola wrote:
From: Brandon Benvie [bben...@mozilla.com]
That would leak the Symbol to the Proxy and then private Symbols wouldn't carry
a guarantee of security. That's the only difference between private Symbols and
unique Symbols.
Right, I thought about
On 8/2/2013 1:21 PM, Tab Atkins Jr. wrote:
On Fri, Aug 2, 2013 at 12:45 PM, Kevin Smith zenpars...@gmail.com wrote:
class C {
sys/iterator() { }
foo/userDefined() { }
}
How do you distinguish these from plain strings? Or are you not
distinguishing them, and just
On 8/2/2013 1:31 PM, Erik Arvidsson wrote:
You can already use string literals as property names:
```js
class C {
sys/iterator() {}
}
```
Oh right, method syntax threw me off, but this is completely valid.
___
es-discuss mailing list
On 7/30/2013 9:39 AM, Brendan Eich wrote:
Brendan Eich wrote:
I just mean an instance of a Map or a class that extends Map.
Essentially all I'm saying is that you match by [[Class]] (which
doesn't exist in ES6, but a heuristic to determine what is
essentially [[Class]] does exist).
On Jul 29, 2013, at 5:26 AM, Kevin Smith zenpars...@gmail.com wrote:
The defining feature of symbols is that they are unguessable, but this
feature is useless in the context of unique symbols, since one can always
just get to the symbol by property inspection. As such, symbols appear to
On 7/29/2013 10:03 AM, Kevin Smith wrote:
Are you arguing that non-enumerability is a useful encapsulation
mechanism?
I believe enumerability has a propensity to get in the way of encapsulation.
The main use case that I've seen for for-in and Object.keys is using a
plain object as a map.
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design protocols
without having to globally coordinate on property or method names.
(E.g. iterator)
I think {keys, maps, values} (and the pivot to using Symbols and
functions for them)
On 7/29/2013 1:09 PM, Brendan Eich wrote:
Brandon Benvie wrote:
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design
protocols without having to globally coordinate on property or
method names. (E.g. iterator)
I think {keys, maps, values
On 7/29/2013 1:29 PM, Brendan Eich wrote:
More recently, Jason implemented 'iterator' for two reasons, I think:
1, lack of symbol spec of implementation as prerequisite; 2, belief
that a public name was better. Jason argued that case here, but I
don't think he prevailed (Dean Landolt
On 7/29/2013 4:04 PM, Brendan Eich wrote:
Regarding realm associations? What is the rationale for making the
typeof binding per realm? I would expect the people would want (at
least operator associated) value object instances to be freely used
across realms, just like numbers, strings, and
On 7/29/2013 4:47 PM, Brendan Eich wrote:
Brandon Benvie wrote:
For value objects, I think it would be problematic if `1m +
iframeEval('1m')` or `1m === iframeEval('1m')` didn't work. It would
also be a shame if my user-overloaded `new Point(0, 0) +
iframeEval('[5, 5]')` didn't work.
Really
On 7/29/2013 5:20 PM, Brendan Eich wrote:
Honing in on disagreement (rest is ok).
Brandon Benvie wrote:
I don't see an issue with using a string to identify a builtin type
for user operator overloading though, since you don't end up with
multiple copies of the same user type. If my
On 7/29/2013 5:14 PM, Brendan Eich wrote:
David Bruant wrote:
Also, I fail to understand the difference between if O is an exotic
X object and if O.[[Class]] === X.
+1
What have we gained?
It seems to me like duck-typing based on internal properties was
basically superseded by @@create
On 7/26/2013 11:53 AM, Michael Haufe wrote:
A useless parameter is an option:
_= 'foo'
This seems to be an argument in favor of making the params completely
optional. The fact that throwing in a useless param is more concise than
having zero params (due to paranthesis requirement).
I
On 7/25/2013 1:31 PM, Erik Arvidsson wrote:
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
Having those properties be enumerable is very
On 7/25/2013 1:31 PM, Erik Arvidsson wrote:
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
Differences from Symbols:
* enumerable
* visible to
On 7/25/2013 5:31 PM, Erik Arvidsson wrote:
It is not clear what private state will look like. The relationship
work Mark has done looks promising but it is not yet clear that we
need both private state and unique symbols.
Right, what I'm saying is that unique Symbols and private state
On 7/23/2013 9:00 AM, Till Schneidereit wrote:
Given that, I don't see how we can expect to be able to land
Array.prototype.values in any meaningful timeframe and think dropping
it or changing the name should be considered.
Bikeshed time! I submit vals and items.
On 7/19/2013 9:52 AM, Allen Wirfs-Brock wrote:
Even if you could, I highly doubt that proxy performance will ever be
up for the task, at least not for an implementation cost that isn't
much higher than the special casing.
Like I said, I don't see how this is a performance issue for Symbols
Another factor I haven't seen mentioned but that I think is important is
introducing a new primitive that has no literal form is another rough
edge/inconsistency that will be confusing. Having to use a factory to
make them makes me want to use `new` with that factory. But using `new`
should
On 7/17/2013 1:30 PM, Allen Wirfs-Brock wrote:
Didn't we discuss making the [[DateValue]] immutable when a Date object is
non-extensible? I see this isn't currently in the ES6 draft. Also, thinking
about it now, that seems like quite a one-off hack.
It also brings up the question of, for
On 7/17/2013 3:58 PM, Claude Pache wrote:
Le 17 juil. 2013 à 18:43, Andreas Rossberg rossb...@google.com a écrit :
If users ignore them anyway, why would they care?
If symbols are primitives with wrapper, they *must* care: They must know that
`new Symbol` does not produce a new symbol, but
On 7/17/2013 4:02 PM, Brandon Benvie wrote:
And this is how it currently works in the V8 implementation. The first
thing I did testing it looked like:
var s = new Symbol();
var x = {};
x[s] = 'test';
I was surprised to find that this threw an error instead of doing the
(to me
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
current timezone?
What happens if the timezone changes between the creation of two Date
objects, such as for
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
current timezone?
What happens if the timezone changes between
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date
On 7/17/2013 4:55 PM, Jonas Sicking wrote:
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than
On 7/16/2013 4:56 PM, Brendan Eich wrote:
Mark's suggestion seems better because it throws on random wrong this
but supports strict calls by unqualified name.
I don't think that it'd be nice if `Map()` could throw or not throw
depending on strictness of the caller. Working around that
On 7/16/2013 5:09 PM, Mark S. Miller wrote:
Nit: All calls. The non-coercion of |this| depends only on the
strictness of the callee, not the caller.
Ah yes, right! Nevermind on the complaint in my last message.
___
es-discuss mailing list
On 7/15/2013 10:24 AM, Jeremy Martin wrote:
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint
satisfy the shallow generator requirement? As I understand it, the
issue with deep generators and CPS transformations is that the
transformations have to be applied to functions
On 7/15/2013 5:52 PM, Allen Wirfs-Brock wrote:
A new ES6 draft is now available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
This is the Rev 16, July 15, 2013 draft.
The bookmarks/index in the PDF versions has a lot of extra cruft in it
(1, 1, 1, 1, 1.1, 1.1, 1.1,
On 7/11/2013 4:37 PM, Andrea Giammarchi wrote:
my problems is that generators were not needed there ... values() as
array of values, keys() as array of keys and items() as array of
key/value pairs.
This is even **easier**
Generators because you wrote them in PHP ... this, is non sense to me
On Jul 1, 2013, at 7:23 AM, Juan Ignacio Dopazo dopazo.j...@gmail.com wrote:
So, in the light of modules, are static methods necessary?
Static methods that use the |this| value to allow for constructor-side
inheritance don't work correctly if simply imported from a module.
See Array.from
On 6/27/2013 3:19 AM, Marius Gundersen wrote:
Or maybe it just isn't implemented in Firefox?
This is correct. https://bugzilla.mozilla.org/show_bug.cgi?id=884372
___
es-discuss mailing list
es-discuss@mozilla.org
On 6/25/2013 10:33 AM, Allen Wirfs-Brock wrote:
We could make an exception for iterator, but why? That just introduces
an inconsistency in the design.
I think the motivation was to make it easier to polyfill, but I don't
think that argument holds for @@iterator. If you're attempting to
On 6/25/2013 1:09 PM, Jason Orendorff wrote:
On Tue, Jun 25, 2013 at 12:33 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This design discussion really wasn't just about iterator. In ES6 we have
various property keys that are hooks deeply into either the semantics of core
language
On 6/25/2013 2:17 PM, Jason Orendorff wrote:
On Tue, Jun 25, 2013 at 3:19 PM, Brandon Benvie bben...@mozilla.com wrote:
It's not just about backward compatibility, but also usability. Mandating
the addition of a non-symbol property in order to work with a protocol (in
this case the iterator
For reference, this is the thread:
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028661.html
On 6/24/2013 9:31 AM, Allen Wirfs-Brock wrote:
On Jun 24, 2013, at 8:42 AM, Jason Orendorff wrote:
According to the January 30 meeting notes, Array.from is getting
optional map
On 6/24/2013 9:42 AM, Domenic Denicola wrote:
That led to further discision of that usage and we got into things like the
last example:
```js
// Turn an array of nodeNames into NodeList of nodes
NodeList.from( [div], node = document.createElement(node) );
```
I think I must be missing
On 6/24/2013 9:44 AM, Brandon Benvie wrote:
On 6/24/2013 9:42 AM, Domenic Denicola wrote:
That led to further discision of that usage and we got into things
like the last example:
```js
// Turn an array of nodeNames into NodeList of nodes
NodeList.from( [div], node = document.createElement
On 6/17/2013 6:30 PM, Brandon Benvie wrote:
On 6/17/2013 4:33 PM, Jason Orendorff wrote:
Firefox added Array.prototype.values() and immediately ran into
compatibility issues.
https://bugzilla.mozilla.org/show_bug.cgi?id=883914
https://bugzilla.mozilla.org/show_bug.cgi?id=881782
Both bug
On 6/18/2013 3:02 PM, Andrea Giammarchi wrote:
can you try to hot-fix that via `with(values.values=values)` ?
That probably works, but it matters little since the hazard is with the
existing installed base of sites that use this which would need to be
updated. I can't imagine standardizing
On 6/17/2013 4:33 PM, Jason Orendorff wrote:
Firefox added Array.prototype.values() and immediately ran into
compatibility issues.
https://bugzilla.mozilla.org/show_bug.cgi?id=883914
https://bugzilla.mozilla.org/show_bug.cgi?id=881782
Both bug reports have to do with Sencha Ext JS. I haven't
On 6/11/2013 5:50 AM, Tab Atkins Jr. wrote:
On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, turning every iterator into an iterable puts the burden
on people implementing iterators: they have to implement the iterable
interface.
That's... not really
On 6/7/2013 10:18 AM, Dean Landolt wrote:
The for/of iterators solve this nicely. This is definitely something
that comes up a lot though, and this seems like a very handy cowpath
to pave. If it were spec'd I'd suggest the naming and argument values
should align with the for/of variants.
My
1 - 100 of 417 matches
Mail list logo
