domenic at domenicdenicola.com (2014-03-06T23:05:05.915Z)
Le 03/03/2014 10:11, Andy Wingo a écrit :
> 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.
Le 03/03/2014 10:11, Andy Wingo a écrit : > On Sun 02 Mar 2014 04:18, Domenic Denicola <domenic at 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