Usage with EventEmitter: pass all arguments to the Stream

[greelgorke]

Hey, Highland looks nice, i'm trying it out currently. What bothers me now is the fact that a stream, that wraps an EventEmitter instance, passes only the first argument with it. It prevents me from doing stuf like

var server = http.createServer()

hls = hl('request', server)

hls.each(function(req, res){
  console.log('consuming ')
  res.end('Holla') // this fails, since res is undefined
})

is it posible to wrap the params in some way and pass them along?

[caolan]

I don't know how we'd do it. Would the arguments be passed as an Array?

[greelgorke]

i don't know either, yet. what i did in my attempt was to establish a convention or better a contract, that everything wat is put to a chain of transforms will be profvided to user code in the same way as consumed. But, nody is more strikt a has a slightly different goal. i currently experimenting, if i can use highland in the same way as i thought about nody. i have three options in mind, to replace nody with highland, to combine them, or to rewrite nody with highland under the hood. i'm testing the first one currenly.

so back to the issue. the problem is that streams are generically working with one value at a time, eventemmiters are not restricted to that. so the ony solution i see is to wrap the values into a container, either an array or object or just pass the arguments object of the event handler. that would work, in fact this is what i do currently in my experiment. it's simple, but i don't like it very much, because the knowledge about the structure of the data is lost then, also you have to deal with that the whole chain. but this might be a minor, since we often deal with that in js. and we always could add a map stream to the chain to rebuild the object. so something like that might be viable:

_('request', httpServer /*optional param, may be for this case only: */, remapFunction)
// and in the constructor the event emitter branch:
if (typeof xs === 'string') {
        ee.on(xs, function () {
            var x = typeof mapperFunction === 'function' ? 
                               mapperFunction.apply( null, slice.call(arguments) ) : arguments[0];
            self.write(x);
        });
    }

of course, as mentioned before, one could add own map stream, so we don't need this remap function here, but the event stream must provide all params to consumers in the first place. with the remaping the highland user can impose it own desired structure on the provided data.

this is simple enough i think. i tried with nody to get to the point, where the user of the lib shouldn't care about wrapping and unwrapping, so she/he just provide functions and can asume all params be fine ordered as expected. this, because nody is meant to be a architecture design tool, specific to provide a generic interface and interaction of modules. i don't think it makes sence for highland to do so, it's purpose seems more generic to me. so the wrapping thinkg would satisfy me for now :)

[caolan]

perhaps you could specify the arguments you'd like to consume as an
additional argument to the constructor?

_(ee, 'request', ['req', 'res']).map(function (x) {
    // x.req and x.res now exist
})

On 4 April 2014 11:37, Gregor Elke notifications@github.com wrote:

i don't know either, yet. what i did in my attempthttps://github.com/greelgorke/nodywas to establish a convention or better a contract, that everything wat is
put to a chain of transforms will be profvided to user code in the same way
as consumed. But, nody is more strikt a has a slightly different goal. i
currently experimenting, if i can use highland in the same way as i thought
about nody. i have three options in mind, to replace nody with highland, to
combine them, or to rewrite nody with highland under the hood. i'm testing
the first one currenly.

so back to the issue. the problem is that streams are generically working
with one value at a time, eventemmiters are not restricted to that. so the
ony solution i see is to wrap the values into a container, either an array
or object or just pass the arguments object of the event handler. that
would work, in fact this is what i do currently in my experiment. it's
simple, but i don't like it very much, because the knowledge about the
structure of the data is lost then, also you have to deal with that the
whole chain. but this might be a minor, since we often deal with that in
js. and we always could add a map stream to the chain to rebuild the
object. so something like that might be viable:

_('request', httpServer /*optional param, may be for this case only: */, remapFunction)// and in the constructor the event emitter branch:if (typeof xs === 'string') {
ee.on(xs, function () {
var x = typeof mapperFunction === 'function' ?
mapperFunction.apply( null, slice.call(arguments) ) : arguments[0];
self.write(x);
});
}

of course, as mentioned before, one could add own map stream, so we don't
need this remap function here, but the event stream must provide all params
to consumers in the first place. with the remaping the highland user can
impose it own desired structure on the provided data.

this is simple enough i think. i tried with nody to get to the point,
where the user of the lib shouldn't care about wrapping and unwrapping, so
she/he just provide functions and can asume all params be fine ordered as
expected. this, because nody is meant to be a architecture design tool,
specific to provide a generic interface and interaction of modules. i don't
think it makes sence for highland to do so, it's purpose seems more generic
to me. so the wrapping thinkg would satisfy me for now :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/60#issuecomment-39551925
.

[greelgorke]

so the highland event handler would do the mapping like

function(){
    var ctx = {}
    names.forEach(function(name, idx){
        ctx[name] = arguments[idx]
    })
    stream.write(ctx)
}

this would be great, yes

[caolan]

and if you wanted them as an array perhaps you could just pass a number as
that argument instead:

_(ee, 'request', 2).map(function (xs) {
    // xs[0] is req, xs[1] is res
})

On 4 April 2014 14:52, Gregor Elke notifications@github.com wrote:

Reopened #60 #60.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/60
.

[greelgorke]

yeah.

i'd be happy to contribute that btw.

[caolan]

Excellent, I await your pull request :)

Also, note that I messed up the argument order a bit there ... it should be
_('eventname', obj, ...) instead of _(obj, 'eventname', ...)

On 4 April 2014 14:59, Gregor Elke notifications@github.com wrote:

yeah.

i'd be happy to contribute that btw.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/60#issuecomment-39567555
.

[greelgorke]

i wondered a bit :)

[caolan]

Fixed by #63