Observable Package

[Nathan Stott]

I packaged up a useful mixin I've been using and put it on github.  I thought it might benefit others as well

http://github.com/nrstott/observable-js/

[Tom Robinson]

I've added it to the catalog. You needed to specify the name of the
github repo since it wasn't identical to the package name, but I went
ahead and did that.

I also pulled in the sizzle package from George.

BTW, one little change I made to tusk is to check for the Rhino engine
and re-execute tusk with the same args if it's an incorrect. Are there
any other engines that can run tusk? I can add them to the whitelist.

However, Kris K noted we should allow engines to specify whether
they're compatible with tusk instead. I'm thinking you could implement
narwhal/tusk-engine.js or something, export a property "compatible"
which would be truthy if it's compatible?

-tom

--
tlrobinson{.net,@gmail.com, on twitter}

> --
>
> You received this message because you are subscribed to the Google
> Groups "Narwhal and Jack" group.
> To post to this group, send email to narw...@googlegroups.com.
> To unsubscribe from this group, send email to narwhaljs+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/narwhaljs?hl=en
> .

[Nathan Stott]

Thanks Tom.  I'll remember that about the repo name in the future.

[George Moschovitis]

observable.mixin(Person.prototype);

I am wondering if we could standardize a 'mixin API'. Currently, I am using:

observable.extend(Target)

but I see no problem with

observable.mixin(Target.prototype)  

can we come to consensus on this?

-g.

On Thu, Dec 10, 2009 at 3:12 AM, Nathan Stott <nrs...@gmail.com> wrote:

I packaged up a useful mixin I've been using and put it on github.  I thought it might benefit others as well

http://github.com/nrstott/observable-js/

--

You received this message because you are subscribed to the Google Groups "Narwhal and Jack" group.
To post to this group, send email to narw...@googlegroups.com.
To unsubscribe from this group, send email to narwhaljs+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/narwhaljs?hl=en.

--
blog.gmosx.com

[Nathan Stott]

To me, 'extend' sounds like inheritance which isn't exactly what a mixin is.  However, I know that a lot of existing libraries (SproutCore, jQuery) use extend, so maybe extend would be better.

[Christoph Dorn]

Thanks for putting this up. It is working out great for me.

Christoph

[Nathan Stott]

Cool.  It has an undocumented "plugins" feature that you might find interesting as well.

I need to put together some more documentation for it.  Any help appreciated in that area :).

[Kris Kowal]

On Mon, Dec 14, 2009 at 9:34 AM, Nathan Stott <nrs...@gmail.com> wrote:
> Cool.  It has an undocumented "plugins" feature that you might find
> interesting as well.
> I need to put together some more documentation for it.  Any help appreciated
> in that area :).

It might be a good idea to discuss convergence among your package's
nomenclature, NodeJS's event emitter nomenclature, and Chiron's event
nomenclature.

http://github.com/ry/node/blob/master/src/node.js#L152-181
http://github.com/kriskowal/chiron/blob/master/lib/chiron/event.js

I'm planning to contribute patches to Node to bring events, promises,
and observers under the same conventions in our frameworks.

Kris Kowal

[Nathan Stott]

That's a good idea, Kris.

One strong point, imo, of my approach is that my 'publish' function is variadic.

As for the namings of the functions, I do like the publish/subscribe metaphors, but I'm not a naming nazi.  I don't like 'send' instead of 'publish' because as a mixin, it needs to have a name that is unlikely to clash.  'send' seems like it would commonly have purposes other than sending signals / events.

[Kris Kowal]

On Mon, Dec 14, 2009 at 12:18 PM, Nathan Stott <nrs...@gmail.com> wrote:
> That's a good idea, Kris.
> One strong point, imo, of my approach is that my 'publish' function is
> variadic.
> As for the namings of the functions, I do like the publish/subscribe
> metaphors, but I'm not a naming nazi.  I don't like 'send' instead of
> 'publish' because as a mixin, it needs to have a name that is unlikely to
> clash.  'send' seems like it would commonly have purposes other than sending
> signals / events.

I am probably going to replace "send" and "Signaler" with "emit" and
"Emitter" to get closer to Node. Jury is still out for everything
though. I'm still not sure whether "publish" and "subscribe" are the
same as "observe" and "signal". Publish and Subscribe *may* be
orthogonal to Observers which in turn may be orthogonal to Events, and
it *might* be a good to keep their nomenclature cleanly separated. If
that's the case, I think Publish and Subscribe should fall under what
is being called PubSub these days, and Observe, Observer, Signal,
Emitter, Event, and Promise would be left to their own domain.

There are names I'd like to see deprecated:

- addEventListener -> observe
- addListener -> observe
- addCallback -> when(callback, errback, progress) or observe("ok")
- addErrback -> when(callback, errback, progress) or observe("error")

To name a few.

And I prefer the label "nomenclator". Godwin's Law! :P

Kris Kowal

[Nathan Stott]

What is the difference you see between SignalObserve and PubSub?  PubSub seems like an "observer" pattern to me.  "Observer" implies polling when you first hear it, but I have never seen it implemented that way except when crossing service boundaries.  PubSub is usually used in SOA to refer to 'events' that cross service boundaries.

Signal and Emit sound lower level to my ear than Publish and Subscribe, but suggest the same functionality.

Kris Kowal

[Kris Kowal]

On Mon, Dec 14, 2009 at 12:45 PM, Nathan Stott <nrs...@gmail.com> wrote:
> What is the difference you see between SignalObserve and PubSub?  PubSub
> seems like an "observer" pattern to me.  "Observer" implies polling when you
> first hear it, but I have never seen it implemented that way except when
> crossing service boundaries.  PubSub is usually used in SOA to refer to
> 'events' that cross service boundaries.
> Signal and Emit sound lower level to my ear than Publish and Subscribe, but
> suggest the same functionality.

It seems like a there are distinct groups of cohesive terms that are
functionally similar. In Codish, that usually means they're begging
for a distinction, or one of them needs to get voted off the boat.
PubSub is more about syndication, like RSS and Atom, in my experience,
and SignalObserver is, like you say, more low level, less about
streams of events and more about a distributed event graph. Events
also imply the existence of "event" objects and may have "bubbling"
semantics or whatever else attached to them based on the Event type.

Here are some equivalence classes:

* signal (v.), emit, publish, (send)
* signal (n.), signaler, emitter, publisher
* observer, subscriber
* observe, subscribe, (addListener, addEventListener)
* event loop
* observer pattern, pub/sub pattern
* ?, feed
* event, ?

Some promise related terms:

* promise (in addition to what it is in other languages (a reference
that gets resolved to a value in place), a type of emitter that emits
"ok" or "error" events exactly once to any number of observers, and
emits the same event to any new observers after it has been resolved.
might be reasonable for it to also have "progress" with some
extensions)
* resolver
* resolve
* reject (break in other languages)
* defer, future (returns a promise, resolver pair)

I can't speak intelligently about what distinguishes a promise,
future, or deferred. Kris and I are thinking of using Future as the
type of a promise, resolver, progress group.

I suspect that something cool and elegant would come out of bringing
all this together, but I'm not sure what yet :P

Kris Kowal

[Nathan Stott]

After reading about it more, I can find no distinction between the observer pattern and the PubSub pattern.  The PubSub terminology seems to have been popularized by the SOA crowd to clearly differentiate themselves from implemtnations of the "Observer" pattern that relied on polling.  That would be the key difference if any.  The "Observer" pattern sometimes has been misunderstood as a polling pattern and PubSub makes it explicit that polling is not involved.

I don't know if Promises can be unified with PubSub.  Promises could be built ontop of PubSub, certainly, but I don't see a unification path beyond that.

Perhaps what we should be trying to unify are PubSub across service boundaries with PubSub inside of a boundary.  This would make promises that are implemented ontop of PubSub able to work across service boundaries with no additional work.  In JS, this unification should be as simple as agreeing on method names.  Maybe there's nothing deeper to discuss than that?

Kris Kowal

[Kris Kowal]

On Mon, Dec 14, 2009 at 4:31 PM, Nathan Stott <nrs...@gmail.com> wrote:
> Perhaps what we should be trying to unify are PubSub across service
> boundaries with PubSub inside of a boundary.  This would make promises that
> are implemented ontop of PubSub able to work across service boundaries with
> no additional work.  In JS, this unification should be as simple as agreeing
> on method names.  Maybe there's nothing deeper to discuss than that?

That's probable.

Kris Kowal