Reason why generators do not have references to themselves?

Bradley Meck bradley.meck at gmail.com
Mon Jan 27 17:29:07 PST 2014


This is more just a comment / thinking out loud about syntax. Not related
to a specific use case. The following is just what was starting to bring my
thoughts around to that though.

I am starting to build things with the constructs in this thread, so
building out things in a similar manner to Promise.[race|all] . Even with
the built ins, some things would just be interesting to have on hand:

I went the same route and made a:
mapPromises(Map<?,Promise<?>>)=>{rejections:Map<?,?>,resolutions:Map<?:?>},
while working out some example problems / speccing out a User lobby system.

I was trying to also figure out a way to dynamically add / remove Promises
while waiting on full resolution. Promises.all is useful, but when working
out people joining / removing themselves in a voting system it is a bit
tough. Ended up making my own function / plumbing for that:
mapDynamicallSpecifiedPromises =>
{promise:Promise<Map<?:?>>,setMappings(Map<?,Promise<?>>)}. This is
probably too much for stdlib though. Being able to dynamically change the
mappings makes for a much easier time if you have a constantly changing
list of users in a room for example.


On Mon, Jan 27, 2014 at 4:49 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Bradley Meck wrote:
>
>> Unsure on how new syntax features like await should deal w/ multiple
>> operands though, like if await wanted to turn multiple promises into an
>> array. Comma operator takes comma separated list out of the equation.
>>
>
> No one proposed this. Do you have a use-case? Task.js and others provide
> combinators such as choose and join, this seems better (compositional, no
> magic/weird reinterpretation of comma).
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140127/09705c2a/attachment.html>


More information about the es-discuss mailing list