Lately there was a lot of attention in English-speaking Flash community to Robert Penner’s AS3 Signals library. I’m surprised because there’s nothing revolutionary and even new in this approach. Yes, this concept is good in special cases. And yes, I agree that Flash events are ugly.
First of all, if you don’t know what I am talking about take a moment to check the library on the web.
Second, read my previous post about silent developers and flash community.
Well, every flash developer earlier or later starts thinking about Flash events system. Events are in the core of ActionScript 3.0 but you might consider their implementation ugly. I’ll be referring to Robert’s post one and post two. Where he says that:
- addEventListener syntax is awkward
public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
I agree that useCapture is only needed for DisplayObject events, but I disagree that useWeakReference should be widely used. This is bad practice adding stuff and hope that it will be somehow magically removed later. You must always unsubscribe manually.
- He doesn’t like Event class properties and methods related only to DisplayObject events. But is having 2 event systems better?
- There should be additional methods like addOnce() or removeAllListeners(). Every experienced developer has already written helpers for these actions. If not more.
- It is not possible to implement IEventDispatcher without using an EventDispatcher object. Yes, trying to extend Flash events model is hard. In fact I saw an implementation of event bubbling through a tree of special objects (which are not DisplayObjects) which mimics standard event bubbling behavior. The code is full of dirtiest hacks I’ve ever seen.
After, Robert proposes his own events model. I’m not saying that the idea is bad. No, it has its pluses and might be used in a couple of small projects. Flash developers are tied to using events by design. Signals and wrapping events just don’t magically solve problems. As I mentioned before, most of experienced Flash developers wrote their helpers and some of them even developed bubbling mechanisms for objects other than DisplayObject.
Flash events are too simple when used out of display list and has some unused code, that’s correct. But they shine if used within display list. Especially if you develop interfaces. Bubbling, capture phase, canceling and stopping events — these are very convenient tools. A lot of the times I find myself catching children events in some common “root” object, for example.
Yes, Signals are simple. But try adding bubbling, phases, canceling and stopping functionality to them and you’ll get plain old Events. Let’s check what else Robert says on the site.
- Removing unnecessary code feels great.
You just remove one code adding another. - Composition and interfaces are favored over inheritance. Events in interfaces are a good thing.
I don’t see this as advantage, events are usually registered with [Event] metatag so Flex Builder can use autocomplete. From numerous public properties I have to find a Signal object I need. - Event types are classes, not strings.
OK, while you don’t have other properties Event class provides you are good. What will you do when you need target, currentTarget and others? Oh, I missed the DeluxeSignal class. Looks like you are going back to Event object. Event types are not only strings either in Flash events. Event type is a class extending Event class + event name. - Event classes should focus on the data they contain, not on who sends them.
Event class contains just enough information listeners need. Consider it an e-mail. What Signals dispatch looks more like huge boxes with different stuff. Do all your listeners need all that? - Event classes should not contain string constants that various other classes use.
Who said that? - So far, not a single “static” keyword in the source.
Static event names are not mandatory, they are used for compile time checking. Consider your own example:progress.dispatch('The Answer', 42); // will succeedIf you pass some kind of a name here you’d create a static constant for it too. In case you mistype it.
I agree that releasing code is good, I agree that using Flash events out of display list might look like shooting flies with a turret, but I don’t understand why people are so excited. Once again,
- Experienced Flash developers have created their own helper classes long time ago
- Signals are good while they are simple
- Some of pluses mentioned are questionable
- I doubt we need 2 event mechanisms and wrappers between them
This is more like a toy.
And last, a lot of people use events wrong. That’s where stuff like data:Object properties in custom events come from.
Totally agree. I just don’t see the point. Native event system is a bit verbose, but it’s doing the job pretty nicely i think…
And runtime type checking with the ‘is’ operator in each dispatch() is one of the ugliest thing I’ve seen so far :)
> runtime type checking with the ‘is’ operator in each dispatch() is one of the ugliest thing I’ve seen so far :)
@tageus,
If someone doesn’t want the runtime type checking on dispatch(), they can leave the Signal constructor blank.
If we had type-safe delegates like C#, I wouldn’t have to resort to this.
The compiler knows all kinds of information about the events and listener signatures, but it isn’t using it. The compiler should tell me if my event handler isn’t set up with the right event parameter.
Can you see a better way to accomplish my goal of type safety within the limitations of AS3?
@RP,
> If we had type-safe delegates like C#, I wouldn’t have to resort to this.
If we had C# Event model (loving the +=), life’d be better !
> The compiler should tell me if my event handler isn’t set up with the right event parameter.
Absolutely true, though hard to implement in the current AS3 event model
> Can you see a better way to accomplish my goal of type safety within the limitations of AS3?
Yes, don’t pass parameters to the callback. That means you’ll have to subclass Signal to store data, or store data elsewhere (signal owner). Type safe but boring :-s
But be sure I’ll give Signals a try in a next project :)
@zwetan
I’m sure flash devs are used to find multiple ways to make things work :)
AS3Signals rocks hard, dude. Try actually using them on a project. I use them on all my projects now and haven’t regretted it for a minute. I think you missed some of the key points here. Using signals means you never have to extend event. This saves a lot of code. I agree with Rob that string constants suck. With signals you don’t need them.
1. As for people creating their own helper classes, most developers I know haven’t – they just took what they were given with AS3 events and tried to work with it.
2. Signals make things simple.
3.Great point?
4.We only need 2 mechanisms because Adobe didn’t do as good a job as Signals does.
You also missed the massive plus that Signals can be defined in interfaces and appear in autocompletion.
Hi Valentin, thanks for your response. It helps me see that some of my statements on the Signals wiki may be unclear. For instance, when I say “Removing unnecessary code feels great,” that means implementing messaging with Signals can take significantly less code than with EventDispatcher. When I migrate an app from AS3 Events to Signals, yes I am swapping syntax, but the diffs show a lot more red than green, if you know what I mean.
With Signals, I don’t need to create Event subclasses to store my value objects. I just dispatch the value objects themselves. And if I want to dispatch, for example, a uint and an Array at the same time, a Signal can do that, without forcing me to create a wrapper class.
I would agree that for many developers, EventDispatcher is good enough. It’s not good enough for me. I currently have 10 points in my Signals features page:
http://wiki.github.com/robertpenner/as3-signals/features
These are all things that EventDispatcher doesn’t give me. Some developers are excited by Signals features and find them useful in their projects. From the beginning of Signals, I have felt that it will be hard for many developers to adopt something new when AS3 Events are an accepted standard. The benefits of the new system have to be substantial in order to go to the effort of migrating. But the last two weeks have been quite encouraging, as early adopters have been posting and giving enthusiastic feedback.
I will respond to more of your points later. Thanks again for your response.
A few thoughts in response to this:
“I’m surprised because there’s nothing revolutionary and even new in this approach”
Who is claiming that the Signals “pattern” if you will, is revolutionary?
( About using weakReference )
“…This is bad practice adding stuff and hope that it will be somehow magically removed later”
Regardless, I think it is still a good habit and very literal to declare that you want an event listener to be “weakly referenced” at the time of its subscription.
“Signals and wrapping events just don’t magically solve problems”
Again, who is making the claim that using Signals, in this case Robert Penner’s library, is going to “magically” solve your problems? Any developer worth their salt knows that a library such as this is supplementary.
I think it’s great that Robert Penner took the time to implement Signals in AS3. Sure, its nothing new… but its nice that *someone* finally is sitting down and formalizing a library for AS3 (sorry if I’m leaving others who have done the same out). I haven’t myself witnessed a lot of over-eager hype around it as you are claiming in this post. In comparison I have used the pattern in other languages and have been quite pleased with the outcome.
I don’t get it too much either, but I am kinda curious on where this is going to end. So I will sit back, relax and enjoy the show.
I agree with you. For the most part, simply because i don’t find the AS3 event model to be the monster some people make it out to be. Certainly not enough to add my own proprietary model.
I think introducing “double standards” is problematic for a language as (relatively) consise as AS3. While discussion and publication of code is incredibly valuable, i think time spent icepicking away at the foundations of the basic language does less good than it causes confusion, especially for beginning developers.
My general suggestion is “Hey guy, use what works for you”. But the notion that X is “better” than Y for reasons such as personal preference and semantics isn’t bringing the community forwards.
I think maybe Penner’s work has been somewhat colored by how public his personal opinion of AS3 events has been. Twitter can be a real bitch like that.
I agree. But I like the fact that Robert is trying new things with because new ways of handling comms is good to show that we shouldn’t be tied to Actionscript’s built-in way of doing things. I have been using lowra framework for some time so am used to having removeListeners [ all ] but also addListener [ for all object's events ]. I think that custom subclasses of Event are good – they let your application grow naturally. Signals seems to concentrate on solving some of the bad points of flash’s event system but doesn’t warrant wholesale replacement of the Event as the object of communication. The weak listener argument is not that important ( you should/must manually remove listeners when appropriate ) and this is not a big issue for a good developer.
Personally I prefer to have subclasses for different event types. Having compile-time checking against my events is very convenient, and it means that I don’t need to hunt down the code that dispatches the event to find out what the payload will be.
After using AS3 events extremely heavily for a couple of years now (off of the display list, no less). My experience has been pretty positive.
I don’t think that enough value is added to justify having to work with two systems to get the job done.
@Andreas,
“Proprietary” means exclusively owned and controlled. Signals is open source under the MIT license; it is not proprietary. I don’t own Signals or have exclusive rights to it.
http://en.wikipedia.org/wiki/Proprietary_software
AS3 events are based on DOM Level 3 Events, which is a W3C standard. But where is the source code for Adobe’s implementation? I can’t find it in Tamarin. If you find the source for EventDispatcher, please let me know. It’s a black box.
With Signals, the code is all there for you to see. If you find a bug, you can fix it. On the other hand, Adobe managed to make it impossible to even write your own implementation of IEventDispatcher. EventDispatcher has native code at its core which changes Event instance properties that AS3 cannot.
Hi there,
I gonna try to comment on other angles to keep that constructive.
First, I’m pro open source and I believe that ideas have no value
only implementations have value.
So whatever some dev could tell “duh we were doing that in 2007, nothing new”,
well sorry guys but you kept it to yourself and didn’t even try to share it
with the flash community, nothing bad with that but here we’re talking about
something open source that anyone can use and learn from, this have a lot of
value at the community level.
Second, even if something is not revolutionary or already done, it is always
interesting to compare “way of doing things”, because our community work as
a kind of “peer review” mechanism, but this can only happen if you show something
out there, wether it’s snippet of code in a blog or an open source lib,
the only way to have a discussion or review started is to show something.
Third, the people in the flash community are very different to one another,
so about events in AS3, I can tell you I saw more people not defining a clone
method and using the dreaded data:Object = null 2nd arguments than people
“correctly” using events, but that’s the point: there is not a really a
single correct way of using events, it really depends on your needs
as a solo dev or as a team, if you use pure AS3 or Flex, etc.
So let take one illustrative example,
“Event classes should not contain string constants that various other classes use.”
who said that you ask ?
well, let me try to explain that with enums,
if you look at the Flash API, Flex framework etc. you will see that
everywhere the “standard” is to define a class that contains static const
typed as strings.
Now I can argue that in certain case it is much more preferable to type your enums
and so “use class as enum”, for events it is the same logic.
I know a bunch of developers in the flash community that not gonna reuse the const
and directly write a string when they dispatch their event and that is very bad,
forcing a type for your events (or your enums) would give no choice to reuse the type
as you could not replace it by a string.
public class MyEvent extends Event
{
public static const CLOSE:String = “close”;
//…vs…
public static const CLOSE:MyEvent = new MyEvent( “close” );
}
for some, it is very important that a dev could not replace MyEvent.CLOSE by “close”,
for other it would be more important to use a string const because it’s lighter for the memory,
I’m not saying one way is better than another I just try to show why it can be bad in some cases.
So sure at the end you can do everything the “standard” way and just use events,
but I can guarantee that there are some case where signals or even a simple callback function
are much much much better.
You will not use “standard” events for either types, speed (in non UI) and a lot of
other subtle context, etc.
The excitement in all that, I guess, is that it can make some dev realize that
“you can do things another way” where they tought only the “standard” way was possible.
@Robert:
you’re right there is no implementation of events in Tamarin,
it would be nice if Adobe could add it, but in most case
with a sleep() function and some callbacks you can just make thing works ;)
to Valentin Simonov:
“I saw an implementation of event bubbling through a tree of special objects (which are not DisplayObjects) which mimics standard event bubbling behavior. The code is full of dirtiest hacks I’ve ever seen.”
Could you post the link to that implementation?
It truly is a esoteric subject.
Is there anyone out there that can get Robert Penners codes to
work without a class redefinition.