September 9, 2009

The Community Responds to AS3 Signals

The community response to my Signals event system has been very encouraging. In the two days since I opened it to the public, there have been dozens of comments on my announcement and re-tweets. People have been quite positive and interested. No one has told me I'm wasting my time (you could be the first!).

The best part has been people's insights for improving Signals. I'm been rapidly integrating them as you can see in my commits for the last two days. A special thanks goes out to Richard Lord for helping me understand AS3 event bubbling and how to implement it in Signal.

Connecting EventDispatchers to Signals


[EDIT: I renamed EventDispatcherSignal to NativeRelaySignal]

I received a very clever idea by Jacob Wright for relaying EventDispatcher events to Signal listeners. I implemented it in a new EventDispatcherSignal NativeRelaySignal class. It lets you easily wire, say, a Sprite to send native events through your own signals. The same goes for any object that implements IEventDispatcher.

Here's how you could create a Sprite subclass that uses a Signal for the click event:

public function MySprite()
{
 click = new NativeRelaySignal(this, 'click', MouseEvent);
}

// listen elsewhere
function onClick(e:MouseEvent):void { ... }

mySpriteInstance.click.add(onClick);
// fire a MouseEvent manually to test
mySpriteInstance.dispatchEvent(new MouseEvent()); // onClick is fired

The implementation of wiring the Signal to the IEventDispatcher is very simple:

[EDIT] I added listener count checking to avoid bugs (thanks to Richard Lord).

// in NativeRelaySignal.as
override public function add(listener:Function, priority:int = 0):void
{
 var prevListenerCount:uint = listeners.length;
 // Try to add first because it may throw an exception.
 super.add(listener);
 // Account for cases where the same listener is added twice.
 if (prevListenerCount == 0 && listeners.length == 1)
  IEventDispatcher(target).addEventListener(_name, dispatch, false, priority);
}

Also, Jacob's twin Tyler sent me some mind-bending ideas for radical memory efficiency. He takes lazy instantiation to a whole new level. I'm still reeling from thinking about things like Signal inheriting from Array and using a getter's arguments.callee as an index into a Dictionary. We'll see how this evolves.

Github vs Google Code


Question: Who would prefer using Github for the Signals project, rather than Google Code? I've used Git a bit and would be open to moving to it if contributors preferred that.

20 comments:

Richard Lord said...

Hi Robert

Thank you for the mention.

re: GoogleCode vs GitHub. Either choice works for me personally. But I think that Git is still in early adopter territory. It is the way of the future, but the client tools for working with SVN are more refined and more developers have everything they need already installed.

noebef said...

You're wasting your time!

Niels said...

Quite a responsibility you have taken upon your shoulders there: I'm holding off a project until this Signals things is usable for me. I think this is going to save me a lot of headaches...

Michiel van der Ros said...

As far as I know, Google Code is the most common place for open source AS3 projects.
So I'd stick with that unless there are some major advantages at Github.

shaun said...

GitHub GitHub GitHub!!! I do realize that most Flash devs are still using SVN. But there is no beating the level of collaboration that GitHub can offer the project.

Besides, having a couple of high-profile Flashers (that's you buddy!) host their projects on GitHub could really help push more Flashers over to Git. I don't know of anyone who has regretted learning Git. It certainly changed how I think about software development and collaboration.

Marc said...

I love the signals concept.

As I mentioned in a tweet, the main worry I have is having multiple event frameworks in place. I think back to the AS2 days where we might have 2,3, or 4 different event frameworks in an application and that scares me.

I'm really interested in improvements like this since it brings signals closer to events in compatibility.

codecraig said...

github sounds good. I'm a Java/Flex guy and I've used SVN for years...I just started using git (and github) yesterday and I'm like what I see :)

codecraig said...

...i don't think you wasted your time :)

Peter Lorent said...

GitHub please.

wezside said...

Github +1!

Arpit said...

If you are really hoping for collaboration with the community Github is the way to go. I have gotten quite a bit more mileage out of that than I ever did with SVN. I wrote a blogpost on "Why Git" here: http://bit.ly/1CQPq1

Stephen Koch said...

Github.

Looking forward to testing this out.

Joel Hooks said...

GitHub is the way to go if you want collaboration. The ability to fork really adds a new dimension that SVN can't touch.

Till Schneidereit said...

I'd recommend using GitHub and hosting a read-only mirror in svn. That way, you get the advanced features of git while allowing devs without git experience to use svn.

I found this tutorial to be helpful in setting that up:
http://blog.nanorails.com/articles/2008/1/31/git-to-svn-read-only

Robert Penner said...

Looks like Github wins this round.

@Richard, someone who would even consider using a new event system is probably an early adopter anyway. =) Brave souls...

Bart said...

Please don't force me to learn linux-esque commands with cygwin. As long as there's no GUI tool for GIT, like Tortoise for SVN, I'm not keen on using it.
Did you know there are actually not-so-tech-savvy Flash designers that like to use opensource projects?

codecraig said...

@Bart - yes I think people realize not everyone is "tech-savvy". And in the case you prefer a GUI to help you with version control you could use an IDE (i.e. Eclipse, IntelliJ IDEA, etc) or even try Tortoise Git (http://code.google.com/p/tortoisegit/).

I googled, "GUI for git" and the second result took me to the Git Wikipedia page which lists at least 2 GUI apps for git :)

nek said...

Github!
Talking about GUIs for svn, cvs, git, mercurial etc... most of them are explorer shell extensions and could make win xp explorer really slow.
So I prefer to use command line versions. GIT + cmd = love!

Robert Penner said...

The majority of you requested Github and I have moved Signals there:

http://bit.ly/wegitsignal

I will experiment with mirroring back to the Google Code project.

Anonymous said...

where is the has() function? as in knowing if a signal has a handler. hmmmm..
I came across a scenario where I wanted it and it wasn't there.

what gives?