iterator next method returning new object

Andrea Giammarchi andrea.giammarchi at
Mon Mar 2 11:19:38 PST 2015

about preventing jerkiness around the object passed around ...

with some logic similar to this one:

function proxiedOwnValues(obj) {
  return Object.freeze(Object.keys(obj).reduce(function (o, k) {
    return Object.defineProperty(o, k, {
      get: function () {
        return obj[k];
  }, Object.create(null)));

we can have one object per generator, and one passed around via `.next()`
so that

// not exposed
var internal = {value: undefined, done: false};

// returned via .next()
var passedAround = proxiedOwnValues(internal);

// when the value gets updated
internal.value = 123;

// is reflected in the outer world
passedAround.value; // 123

// when everything is done
internal.done = true;

// is reflected as well
passedAround.done; // true


So we have preserved contract, people stopping polluting objects they don't
own, and read only operations that could be optimized even more behind the

Does any of this make sense?

Best Regards

On Mon, Mar 2, 2015 at 7:06 PM, Jason Orendorff <jason.orendorff at>

> The most important things here are:
> 1.  Like all performance hacks, unless you've measured a speed
> improvement under fairly realistic workloads, you shouldn't do this.
> 2.  Whenever you need a custom iterator, try writing a generator
> instead. It's amazing. You can get the behavior you want in a fraction
> of the developer time, with clearer and *much* smaller code.
> As to your question, here are some (additional) seeds of doubt as
> requested:
> -   Storing this object isn't entirely free. You have to create a
> property (or closed-over variable, same deal, roughly) to stash it in,
> and each time .next() is called, you have to access that property or
> variable. Also, storing the object prevents the most-recently-iterated
> value from being GC'd. (Normally this won't matter. It could matter if
> you have thousands of iterators going at once, and each one is only
> occasionally consulted.)
> -   If the caller is a jerk, they might do something like freeze the
> object (which means your .next() method will keep getting called
> forever, since it can't set .done to true) or replace the .value
> property with an accessor, and then perhaps your next() method would
> throw or something. You probably never care about stuff like this, and
> that's OK. Certain very rare users do have to care. Worse, your JS
> engine's JIT does have to care.
> -   The statement `return {value: v, done: false};` can't fail,
> whereas `cachedObject.value = v` can fail, in the unlikely cases
> described above, or can trigger a setter, and therefore may require
> your JS engine to check something each time you do it. That's extra
> work and it could slow things down.
> -   The JS engine might be smart enough (if not now, then a year down
> the road) to optimize away the temporary object created by `return
> {value: v, done: false};`. If it does, then using a new object is
> probably better for your JS engine's optimizer, because getting .value
> or .done off of that object is *guaranteed* to produce `v` and
> `false`, respectively, with no side effects and no possibility of
> triggering any getters, setters, proxy traps, etc.
> -j
> On Sat, Feb 28, 2015 at 4:52 PM, Mark Volkmann
> <r.mark.volkmann at> wrote:
> > I know there was a discussion about this recently, but I don't recall
> seeing a reason why it would be problem for a custom iterator to return the
> same object over and over with different values for the value and done
> properties. I tried this in some sample code using Traceur and Babel and it
> works fine. What are the potential problems with doing that?
> >
> > ---
> > R. Mark Volkmann
> > Object Computing, Inc.
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list