Fwd: Re: [CommonJS] Events/A

[Kris Zyp]

Here is Kris Kowal's response to "What about http://www.w3.org/TR/DOM-Level-2-Events/", apparently he accidentally sent it only to me, AFAICT:
-------- Original Message --------

Subject:	Re: [CommonJS] Events/A
Date:	Thu, 4 Feb 2010 12:32:47 -0800
From:	Kris Kowal <kris....@cixar.com>
To:	Kris Zyp <kri...@gmail.com>

On Wed, Feb 3, 2010 at 11:22 PM, mob <m...@embedthis.com> wrote:

> Kris, could you give a quick overview or a sample of using these. I'm
> not familiar with the role of Signal.

I've added some examples.  A "Signal" is an anonymous emitter,
effectively.  Or, more to the point, an Emitter contains a memo of
named Signals.  It's a primitive that has always existed but has never
been exposed.  Exposing the Signal as in the A proposal permits
complex emission trees to be constructed with a simple API.

> Also, what are you proposing as the lead option A or B?

My preference is A.  If it's deemed to weird, we can backtrack to B.

On Thu, Feb 4, 2010 at 6:28 AM, Kris Zyp <kri...@gmail.com> wrote:
> Is there or should there be a way to indicate the desired order of
> execution of the observer callbacks, specifically when you call
> observe() should there be a way to indicate that you want your callback
> called before the others vs after?

I've added examples that illustrate how this is already possible.

On Thu, Feb 4, 2010 at 7:22 AM, Kris Zyp <kri...@gmail.com> wrote:
> Also, wouldn't it be more useful to have observe() return an object with
> an unobserve() or stopObserving() function?

I've added a dismiss callback to the Signal constructor and specified
that that the "observe" method on Emitter provides such a callback to
remove the signal from its corresponding emitter.  Signals can exist
without an Emitter or parent Signal.  Signal is to Function as Emitter
is to Method.

On Thu, Feb 4, 2010 at 8:14 AM, Ryan Dahl <coldre...@gmail.com> wrote:
> 'Signal' already has a technical meaning in a context not too distant
> from this (UNIX) that we shouldn't conflict with.

I'm having trouble conjuring a better name.  Any help is appreciated.

> What about http://www.w3.org/TR/DOM-Level-2-Events/ ?

These would probably do everything we need, but there are a couple shortcomings.

1. For one, Events/A comes in a sleek black casing with the words
"Don't Panic" printed on the back in Comic Sans.

2. Also, my intent with Events/A is to make event emission resemble
method call interceptors more generally than DOM2; DOM2 has an event
object that is passed as the first argument which contains all of the
event state. I think plain arguments are better for the job.

3. The DOM2 API doesn't provide the recursive signal observer
approach, which Kris Zyp already mentioned would be desirable.

4. And lastly, I think we can all agree that the DOM2 method names are
criminally verbose.  Conspicuously, you appeared to be unable to use
the full "addEventListener" method name in NodeJS, truncating it to
"addListener".  This is a step in the right direction.

I have anticipated resistance particularly on the point of returning
new Signal objects whenever you observe another Signal.  There are
alternate, albeit less succinct, approaches that we could explore.

We could also just rework DOM2 to suit our needs.

Alternate proposals would also be helpful.

If you folks could speak your preferences in the matter, it would be
most kind.

My hope is that, since other issues are blocking on this, we could
come to some kind of agreement on a minimal API so we can go forward.

For convenience, here's the latest:
http://wiki.commonjs.org/wiki/Events/A

Kris Kowal

[Kris Zyp]
I'd also point out that http://www.w3.org/TR/DOM-Level-2-Events/ isn't really implemented cross-browser, so the reality is that as web developers, we don't really use it directly very much.

[Darren Hobbs]

On Feb 5, 10:00 pm, Kris Zyp <kris...@gmail.com> wrote:
>
> I'm having trouble conjuring a better name.  Any help is appreciated.
>

Transmitter / Receiver? (I have a mental picture of radio antennae
broadcasting signals to anyone who wants to tune into them)

>
> For convenience, here's the latest:http://wiki.commonjs.org/wiki/Events/A
>

I'm confused how the following code:

var parent = nameEmitter.observe("foo", function ()
{print("parent")});
var child = parent.observe(function () {print("child")});
var beforeChild = child.observe(function () {print("beforeChild");});
nameEmitter.emit("foo");

produces:

parent
beforeChild
child

It looks inconsistent. If beforeChild = child.observe(...) leads to
beforeChild being called before child, why does child =
parent.observe(...) not cause child to be called before parent?

Regards,
-Darren

[Kris Kowal]

On Tue, Feb 9, 2010 at 9:19 AM, Darren Hobbs <darren...@gmail.com> wrote:
> I'm confused how the following code:
>
> var parent = nameEmitter.observe("foo", function ()
> {print("parent")});
> var child = parent.observe(function () {print("child")});
> var beforeChild = child.observe(function () {print("beforeChild");});
> nameEmitter.emit("foo");
>
> produces:
>
> parent
> beforeChild
> child
>
> It looks inconsistent. If beforeChild = child.observe(...) leads to
> beforeChild being called before child, why does child =
> parent.observe(...) not cause child to be called before parent?

You're right, of course. "parent" should print last, not first. I've
revised the examples. Please let me know if you catch anything else.

http://wiki.commonjs.org/wiki/Events/A

Kris Kowal