Proposal: Proxy iteration (`let ... of ...`) trap handler
# Jordan Harband (8 years ago)
Does a trap for [[Get]] on Symbol.iterator not provide you the ability
to intercept iteration by returning a custom function?
Does a trap for `[[Get]]` on `Symbol.iterator` not provide you the ability to intercept iteration by returning a custom function? On Sat, Sep 24, 2016 at 8:34 PM, Tycho Grouwstra <tychogrouwstra at 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 at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160924/009c4f7b/attachment.html>
# saam barati (8 years ago)
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: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols
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 <tychogrouwstra at 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 at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160924/814db2ce/attachment.html>
# Tycho Grouwstra (8 years ago)
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...).
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 <saambarati1 at 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 <tychogrouwstra at 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 at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160925/1806e041/attachment-0001.html>
# saam barati (8 years ago)
It seems like Jordan's suggestion is what you want then.
It seems like Jordan's suggestion is what you want then. - Saam > On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra <tychogrouwstra at 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 <saambarati1 at 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 <tychogrouwstra at 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 at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160924/23d56f11/attachment.html>
# Alexander Jones (8 years ago)
Yes, please don't special case for-of handling, it's nicely expressed in terms of other concepts.
Yes, please don't special case for-of handling, it's nicely expressed in terms of other concepts. On Sunday, 25 September 2016, saam barati <saambarati1 at gmail.com> wrote: > It seems like Jordan's suggestion is what you want then. > > - Saam > > On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra <tychogrouwstra at gmail.com > <javascript:_e(%7B%7D,'cvml','tychogrouwstra at 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 <saambarati1 at gmail.com > <javascript:_e(%7B%7D,'cvml','saambarati1 at 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/Refe >> rence/Iteration_protocols >> >> - Saam >> >> On Sep 24, 2016, at 8:34 PM, Tycho Grouwstra <tychogrouwstra at gmail.com >> <javascript:_e(%7B%7D,'cvml','tychogrouwstra at 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/JavaS >> cript/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 at mozilla.org >> <javascript:_e(%7B%7D,'cvml','es-discuss at mozilla.org');> >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160925/d16a5ab4/attachment.html>
I'd like to propose adding support for an iteration trap handler for Proxy, fleshing out the list of currently supported Proxy handlers. 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 on usage of such a trap, but I'm not sure that would complicate implementation.