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:
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.
You're wasting your time!
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...
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.
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.
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.
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 :)
...i don't think you wasted your time :)
GitHub please.
Github +1!
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
Github.
Looking forward to testing this out.
GitHub is the way to go if you want collaboration. The ability to fork really adds a new dimension that SVN can't touch.
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
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...
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?
@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 :)
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!
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.
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?
Post a Comment