incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <gtan...@gmail.com>
Subject Re: [DISCUSS] Switching out Channel's in callback-js for an event module
Date Tue, 06 Dec 2011 22:11:34 GMT
And that is why you shouldn't start an email 5 days before you finish it.

Key point is I like the eventEmitter idea better.

Ignore everything I wrote before the two examples as I was young and nieve
;)

On Tue, Dec 6, 2011 at 5:09 PM, Gord Tanner <gtanner@gmail.com> wrote:

> You can probably see where I got the inspiration from then ;)
>
> The API is basically the same as the EventEmitter except that the
> EventEmitter from node allows you to new up other event emitters, where our
> module is a singleton instance.
>
> I wouldn't know where to store the instance of the eventEmitter if we did
> use the node pattern.  Ideally we shouldn't need to import anything into
> the window object (other than the device APIs) so that would rule out
> making window.PhoneGap an instance of an event emitter.
>
> I personally like the lack of flexibility of having one central place
> where all events are triggered and acted upon.
>
> Basically we ether end up with:
>
> --------
> PhoneGap.on("foo", func);
>
> PRO:
> - allow multiple instances of EventEmiters
> - can be used as a base class.
> - Syntax that is close to what we have now.
>
> CON:
> - forces storage of shared eventEmitters in the global space
>
> --------
> or:
> --------
> var event = require("phonegap/event");
> event.on("foo", func);
>
> PRO:
> - can be used in a decoupled fashion in any module
> - no requirement of hanging shared emitters off of the window object
> - all events are funneled by the same emitter.
>
> CON:
> - only one event emitter to rule them all.
> - all events are funneled by the same emitter.
> ---------
>
>
> I personally am liking the EventEmitter Approach a lot more as I would
> like to have the ability to separate some of the events by instance:
>
> var phonegap = require("phonegap");
>
> phonegap.on("nativeready", func);
>
> var network = require("phonegap/network");
> network.on("ready", func);
>
> var device = require("phonegap/device");
> device.on("ready", func);
>
> Thoughts?
>
> Gord
>
>
> On Thu, Dec 1, 2011 at 5:12 PM, Patrick Mueller <pmuellr@gmail.com> wrote:
>
>> On Thu, Dec 1, 2011 at 16:48, Gord Tanner <gtanner@gmail.com> wrote:
>> > Please see reference branch here:
>> > https://github.com/gtanner/callback-js/tree/event
>> >
>> > One of the issues with Channel's in a module based system is that it is
>> > awkward to keep track to a central repository of channel objects.
>>
>> I guess I'm a n00b.  I don't know what a Channel is.
>>
>> > I coded up a quick prototype using an event module.  This gives us the
>> > ability to trigger and sync on events by just using a string (rather
>> than
>> > an instance created before hand). It cleans up some of the code and
>> doesn't
>> > require the pre-construction of all the channels before hand.
>>
>> Your API is actually fairly close the nodejs's "events" module:
>>
>>    http://nodejs.org/docs/v0.6.3/api/events.html
>>
>> Close, but different.  In addition to the shape being different, the
>> receiver/subject of the functions/methods is different - in your case,
>> the subject is a global string identifying the event itself; in node's
>> case, events are objects which are instances of EventEmitter, with
>> method names closely corresponding to some of your function names.
>>
>> So, here's an alternative strategy:
>>
>> - implement a compatible nodejs "events" module
>>
>> - implement a separate module which has a list of the global events we
>> think we'll need, with the ability to add more, somehow.  Those global
>> events would, of course, be instances of our compatible EventEmitter
>> class.
>>
>> The only thing I wonder about is "implementing a compatible version of
>> a nodejs module".  You'd think that would be a kosher thing to do, at
>> least if you did it in a clean-room fashion.  But, who knows these
>> days.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message