Another option would be to throw. Then the caller can tell that they did something that was not expected by the inner iterator.
On Sat, Jan 31, 2015, 08:43 Salvador de la Puente González < [email protected]> wrote: > From my point of view, it should do nothing if there is no throw() method > to call. The problem you are pointing is worthy to be noted but is a > problem for the implementer. > El 31/01/2015 04:29, "Allen Wirfs-Brock" <[email protected]> escribió: > > Generally, we want yield* to be as transparent as possible, so that if we >> have a Iterable Inner and a generator defined like: >> >> function *wrapper() { >> yield *Inner(); >> } >> >> any sequence of next/throw/return method calls on an iterator produced by >> wrapper will generate the same results as if the same sequence of method >> calls had been directly applied to the Inner iterator instance that is >> wrapped. >> >> And this generally works (or at least will after I finish fixing some >> bugs) if wrapper and Inner are both generators. But here is the edge case >> where it appears impossible to achieve full transparency. >> >> Generators always[*] have both a "return" and "throw" method and >> everything works transparently as expected. However, if the iterator >> returned by Inner is not a generator object, it might not have a "throw" >> method but still have a "return" method. Normally a "throw" to such a >> wrapper iterator would be forwarded by yield* to the inner iterator's throw >> method, presumably triggering any "finalization" processing needed by the >> inner iterator. However, yield* can't forward the the throw to a >> non-existent inner "throw" method. But the existence of a "return" method >> is a strong hint that the inner iterator may have some "finalization" it >> should be given an opportunity to perform. >> >> It seems like, there are two plausible semantics for this case, each with >> an undesirable characteristic: >> >> 1) yield* doesn't invoke anything on the inner iterator in this >> situation. Transparency is preserved, but the inner iterator may have >> "finalization" processing that never gets executed >> 2) yield* invokes "return" on the inner iterator in this situation. >> Inner iterator gets a chance to run its "finalization" processing. But >> full transparency is lost as a method is invoked on the inner iterator that >> that would not have been invoked with the wrapper wasn't sitting in the >> middle. >> >> (Note that wrapper already isn't truly transparent, because it is >> exposing a "throw" method that doesn't exist on the iterator iterator. >> It's possible, that the visibility of the "throw" method is what caused >> the consumer to invoke it, rather than invoking the "return" method.) >> >> So, opinions on which of these alternatives is better? Are there any >> others? >> >> Allen >> >> [*] this situation actually can occur when Inner is also a generator, but >> it requires over-riding the 'throw' method for that generator's instance >> with undefined. >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
