Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine How "times()" Should Handle Asynchronous Functions #9

Open
freeformflow opened this issue Sep 8, 2015 · 3 comments
Open

Comments

@freeformflow
Copy link
Contributor

times is currently just an until-loop that returns an array containing the result of every iteration. I propose adding support for asynchronous functions, but I'm not sure what the best policy would be.

@dyoder
Copy link
Member

dyoder commented Sep 9, 2015

The trick here is that times should be lean and mean because the intent is to use it with benchmark. So I don't want too much overhead.

We could check for a promise-reponses and then loop using a wrapper function. Ex:

times = (f, n) ->
  m = 0
  _f = ->
    if m++ < n
      if (isPromise (p = do f)) then p.then _f else do _f

# synchronous use
times foo, 1e3

# asynchronous use
(times foo, 1e3).then ...

@freeformflow
Copy link
Contributor Author

Right now, times returns an array of each iteration's result. I'd like to retain that property. Would the following be acceptable?

times = (f, n) ->
  m = 0
  results = []
  do _f = ->
    if m++ < n
      if (isPromise (p = do f))
        p.then (r) ->
          results.push r
          do _f 
      else
        results.push p 
        do _f
    else
      results

# synchronous use
bar = times foo, 1e3
assert isArray(bar) == true

# asynchronous use
call ->
  bar = yield times foo, 1e3
  assert isArray(bar) == true

@dyoder
Copy link
Member

dyoder commented Sep 9, 2015

Hm. I think actually we should get rid of this property, since that could consume a great deal of memory unexpectedly. And also ruins the main use case, which is use with benchmark.

OTOH, I can also see the use case you're focused on. I think there might be two functions here. One which converts a function into a producer that executes N times. Technically, this is already possible:

takeN 1e3, iterator f

or (asynchronous case):

takeN 1e3, reactor f

but perhaps this should be a dedicated function? The trick would be determining dynamically whether the function is async or not. I've thought about this a great deal and generally decided to avoid this kind of thing in favor of explicit declaration (as above).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants