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

forEach, index, repeaters, delays, every, batch, stack #13

Open
nikhedonia opened this issue Jun 12, 2015 · 4 comments
Open

forEach, index, repeaters, delays, every, batch, stack #13

nikhedonia opened this issue Jun 12, 2015 · 4 comments

Comments

@nikhedonia
Copy link
Contributor

I imagine schedulers and eventsystems, for now i propose the following functions:

examples:

[1,2,3]
    ::forEach( function(){ console.log(this) } ) // executes func and yields items (1,2,3,1,2)
    ::index() //counts items and yields count-1
    ::takeWhile( function(){ return this<5 } )
  //::foo(...) //and keep the stream goin...

42::toFunction()
    ::every(100) // yields every 100ms
    ::forEach( function(){ console.log(this,new Date() ) }) // console.logs bout every 100ms

[1,2,3]
    ::repeat() // repeats yield'ing 1,2,3 till infinity
    ::forEach( function(){ console.log( new Date() , this ) }) //  yields this and executes given function
    ::delay(1000) // delayed yielding
    ::forEach( function(){ console.log( new Date(), this ) }) //console.log delayed bout 5s

[1,2,3]
    ::repeat()
    ::batch(5) // yields in batches of 5

[1,2,3]
    ::repeat()
    ::stack(5) // pop and yield an element if stack is full 
@jussi-kalliokoski
Copy link
Owner

repeat is a must have, imo - however I'd like to leave async in Trine undecided for now - it's a hard problem to tame and I'd prefer to base things on future standards such as Observables and Streams as they become more stable, rather than invent the most energy efficient fuel car when electric cars are becoming the thing, if you know what I mean. ;) Meanwhile, A General Theory of Reactivity is good reading for immediate solutions outside Trine, as well as planning for the future of Trine.

@jussi-kalliokoski
Copy link
Owner

As for batch - how would it know which kind of a collection to yield? Or would it yield an iterator? If iterator, you could handily compose with to to get the right kind of collection:

function * batch (n) {
  let buffer = [];

  for ( const item of this ) {
    buffer.push(item);
    if ( buffer.length >= n ) {
      yield buffer[Symbol.iterator]();
      buffer = [];
    }
  }
}

[1,2,3,4]
  ::batch(2)
  ::map(to::partial(Array))
  ::to(Array)
  // returns [[1, 2], [3, 4]]

@nikhedonia
Copy link
Contributor Author

Yup, your code describes exactly what i imagined(isn't there a buffer.push(item) missing?)

I don't understand your initial question; why should batch need to know which kind of collection it has to yield? - could it get more than one kind?

EDIT: wrong button pressed... how can i remove the "closed" message?

@jussi-kalliokoski
Copy link
Owner

EDIT: wrong button pressed... how can i remove the "closed" message?

it's ok, no need to remove it :)

isn't there a buffer.push(item) missing?

yes, nicely spotted! fixed - wonder where it went, I tried it before posting and it worked :D

I don't understand your initial question; why should batch need to know which kind of collection it has to yield? - could it get more than one kind?

IMO it shouldn't, should just be oblivious to collection types and unfold iterators only at user will instead. Just making sure I understood what you proposed. :)

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

No branches or pull requests

2 participants