Re: Final iterator spec
On Sun 02 Mar 2014 04:18, Domenic Denicola dome...@domenicdenicola.com writes: You can just do `if (Symbol.iterator in potentialIterable)`. Of course, this can introduce time-of-check-to-time-of-use bugs. Actually calling @@iterator on the iterable is more reliable. Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Final iterator spec
Le 03/03/2014 10:11, Andy Wingo a écrit :
On Sun 02 Mar 2014 04:18, Domenic Denicola dome...@domenicdenicola.com writes:
You can just do `if (Symbol.iterator in potentialIterable)`.
Of course, this can introduce time-of-check-to-time-of-use bugs.
Actually calling @@iterator on the iterable is more reliable.
This only shifts the problem one step without really solving it. Calling
@@iterator may return a non-iterator or may return something that looks
like a iterator ('next' method), but throws when calling 'next'.
I wonder if time-of-check-to-time-of-use bugs can be fully avoided
entirely in JS?
It might be possible to guarantee some properties in TypeScript assuming
all consummers of a piece of code are checked by the TypeScript compiler.
In practice, it looks like JS devs have lived well with solution like
Domenic's one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array detection (was Re: Final iterator spec)
On Mar 2, 2014, at 9:04 AM, Peter van der Zee wrote: Peter van der Zee e...@qfox.nl wrote: On Sun, Mar 2, 2014 at 4:18 AM, Domenic Denicola dome...@domenicdenicola.com wrote: You can just do `if (Symbol.iterator in potentialIterable)`. Does that work cross-frame? On Sun, Mar 2, 2014 at 5:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Yes Okay, was wondering whether that could work for Array detection as well. But perhaps that problem has already been solved, I haven't kept up with that. `if (Array[Symbol.isArray]) ...` feels like a fairly elegant cross frame solution. Depends upon what you mean by Array detection. If you mean is obj an exotic array object (ie, an object that automatically updates the length property value as integer indexed properties are added or deleted) then Array.isArray(obj) detects exactly that. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array detection (was Re: Final iterator spec)
Depends upon what you mean by Array detection. If you mean is obj an exotic array object (ie, an object that automatically updates the length property value as integer indexed properties are added or deleted) then Array.isArray(obj) detects exactly that. Okay cool. Is there merit in consistency for this? Iterators getting an `isIterator()` method perhaps? - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array detection (was Re: Final iterator spec)
On Mar 2, 2014, at 10:58 AM, Peter van der Zee wrote: Depends upon what you mean by Array detection. If you mean is obj an exotic array object (ie, an object that automatically updates the length property value as integer indexed properties are added or deleted) then Array.isArray(obj) detects exactly that. Okay cool. Is there merit in consistency for this? Iterators getting an `isIterator()` method perhaps? They're really different kinds of tests at a low very. Plus, there is not Iterator object to hang such a method off of. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Final iterator spec
I have a concern with these, which isn't 100% related to this thread, but is on the topic of iterators. So, in Dart, we have this nice option of basically saying `if (OBJ is Iterable)`, and we'll be able to know easily if an object conforms to that particular interface. Admittedly, this construct makes a lot more sense in Dart than it does in Javascript, but it would be nice to have some kind of helper which will determine if an object adheres to the Iterable interface. For instance, `Object.isIterable() = true` if the interface is present in the object's prototype. It would be nice to have a convenience function for this largely because it feels like the VM should have an easier time knowing if an object is iterable or not, and may be able to cache its knowledge of the Iterable status of an object, for performance reasons. Maybe it would be good if a helper function like this would also determine that the return value of `@@iterator()` also conforms to the Iterator interface, or maybe that's not super important. But in any case, I could see utilities like this being very helpful. Maybe that ship has sailed, but if something like that would hurt the harmony status of iterators, I would be interested in hearing the specific reasons against it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Final iterator spec
You can just do `if (Symbol.iterator in potentialIterable)`. From: Caitlin Pottermailto:caitpotte...@gmail.com Sent: 3/1/2014 22:01 To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org Subject: Re: Re: Final iterator spec I have a concern with these, which isn't 100% related to this thread, but is on the topic of iterators. So, in Dart, we have this nice option of basically saying `if (OBJ is Iterable)`, and we'll be able to know easily if an object conforms to that particular interface. Admittedly, this construct makes a lot more sense in Dart than it does in Javascript, but it would be nice to have some kind of helper which will determine if an object adheres to the Iterable interface. For instance, `Object.isIterable() = true` if the interface is present in the object's prototype. It would be nice to have a convenience function for this largely because it feels like the VM should have an easier time knowing if an object is iterable or not, and may be able to cache its knowledge of the Iterable status of an object, for performance reasons. Maybe it would be good if a helper function like this would also determine that the return value of `@@iterator()` also conforms to the Iterator interface, or maybe that's not super important. But in any case, I could see utilities like this being very helpful. Maybe that ship has sailed, but if something like that would hurt the harmony status of iterators, I would be interested in hearing the specific reasons against it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Final iterator spec
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 Feb 20, 2014, at 2:27 AM, joe joe...@gmail.com wrote:
A while back, the wiki Harmony draft spec for iterators changed from a
Pythonic StopIteration approach to one where iterator objects return a {value
: iter-value, done : bool} object. It since seems to have changed back. Is
that the case, or am I misreading the situation?
It seems that Tracuer has yet to switch back, and before I bug the developers
on that project I wanted to make sure that StopIteration is, in fact, back.
Thanks,
Joe Eagar
___
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: Final iterator spec
Thanks. Btw, where is the final spec stored?
On Feb 20, 2014 3:53 AM, Brandon Benvie bben...@mozilla.com wrote:
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 Feb 20, 2014, at 2:27 AM, joe joe...@gmail.com wrote:
A while back, the wiki Harmony draft spec for iterators changed from a
Pythonic StopIteration approach to one where iterator objects return a
{value : iter-value, done : bool} object. It since seems to have changed
back. Is that the case, or am I misreading the situation?
It seems that Tracuer has yet to switch back, and before I bug the
developers on that project I wanted to make sure that StopIteration is, in
fact, back.
Thanks,
Joe Eagar
___
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: Final iterator spec
On Thursday, February 20, 2014 9:27 AM, joe joe...@gmail.com wrote: Thanks. Btw, where is the final spec stored? You can find it in the Drafts page: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts. harmony:specification_drafts [ES Wiki]Draft Specification for ES.next (Ecma-262 Edition 6) This page contains a historical record of working draft of the ES.next specification prepared by... View on wiki.ecmascript.org And there is an HTML version here: http://people.mozilla.org/~jorendorff/es6-draft.html - Juan___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
