It seems like Jordan's suggestion is what you want then. - Saam
> On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra <tychogrouws...@gmail.com> wrote: > > Thank you. > > To elaborate a bit, what I'm trying to do is use Proxy so as to enable > FSM-like DSLs, essentially having one Proxy type represent the current > 'state' dictating what DSL you're in, one property access choosing to either > yield a new proxied object, yielding an unwrapped version, or one wrapped in > a different proxy type. > > This is why I'd wanted to be able to trap different operations, as they help > to give ways to distinguish cases (return a wrapped result etc.). The point > would be this would allow a user to 'navigate' something pretending to be a > regular object, even though it isn't (e.g. async values like > Promises/Observables, remote collections too costly to fetch in full unless > needed, decycled versions of the regular object for the purpose of > serialization, you name it...). > > >> On Sun, Sep 25, 2016 at 12:32 PM, saam barati <saambara...@gmail.com> wrote: >> The purpose of the iterator protocol is to be flexible and to work well with >> custom defined iterators. for...of is more or less sugar around the iterator >> protocol. Not sure why you even need a Proxy to easily customize for...of >> behavior for arbitrary objects. >> >> More documentation on the protocol can be found here: >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols >> >> - Saam >> >>> On Sep 24, 2016, at 8:34 PM, Tycho Grouwstra <tychogrouws...@gmail.com> >>> wrote: >>> >>> I'd like to propose adding support for an iteration trap handler for Proxy, >>> fleshing out the list of [currently supported Proxy >>> handlers](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy#Methods_of_the_handler_object). >>> I think Proxy is among the most powerful features of JS, so I find it >>> unfortunate iteration, a common operation, is still missing. No new syntax >>> would be required for this addition. >>> >>> On a side-note, I'd be happy if there were no additional >>> [requirements](http://stackoverflow.com/a/32360219/1502035) on usage of >>> such a trap, but I'm not sure that would complicate implementation. >>> >>> _______________________________________________ >>> 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
