ActionScript 4 feature request: interfaces with events
Interfaces in AS2 and AS3 are only half-baked. You can place methods in an interface but that's only half the equation. The other half, for applications that use the event model, is events. As it stands AS2 and AS3 do not support a method of defining the events that an interface must implement. Going forward, this is essential to have in ActionScript if interfaces are to be useful in the event model. It is not enough to know which public methods an interface supports but which events you can listen for on instances that implement a given interface.
The ActionScript 4 feature request: interfaces with events article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
The ActionScript 4 feature request: interfaces with events article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Paul
I usually handle this by adding a get method for the event type and / or event itself.
function getProgressEventType(): String;
October 17th, 2006 at 12:52 amfunction getProgressEvent(): ProgressEvent;
Tink
agreed!
October 17th, 2006 at 1:40 ampan69
Its a bit of a weird request you’re making. Interfaces are meant to be mandatory to implement by a class that implements that interface. Implementing events depends completly on the situation you are using certain classes in and can’t possible be mandatory to implement.
Making the implementation of events mandatory also destroys the promotion of loose coupling and you might be better of using callbacks, or even worse let a child object have a reference to a parent object to call methods directly.
October 17th, 2006 at 3:21 amaral
Not weird at all. What does an interface provide for you? It provides the safety in knowing that an instance will contain certain methods. That it will know what to do if you call a certain method. Similarly, if you can be certain that an interface will broadcast certain events, you can listen for those.
Here’s a concrete example:
You have an interface, IPreloadable that defines a contract for an object that is preloadable. You might, for example, dictate in the contract that the object must have a load() method that you call to start loading it. One characteristic that defines IPreloadable objects is that you can inspect them to get their current load progress. In the current status quo, the only way to this is to specify an additional method to get the load progress. Let’s call it getProgress(). (Or split this up to getBytesLoaded(), getBytesTotal(), etc.) Now think about what is required when using this: You need to constantly poll that object for its progress. Not good. Not the event model. Instead, what you should be doing is listening for an event. A progress event. But you have no way of specifying that in the interface.
Now, if I could write:
[as]
interface IPreloadable
{
// IPreloadable objects must dispatch progress events
event progress:ProgressEvent;
public function load():Boolean
}
[/as]
Then I could be sure that I could listen for progress events on any object that implements the IPreloadable interface.
Adding events to interfaces in no way destroys loose coupling. Quite the opposite, it promotes interfaces to first class citizens in applications built on the event model and allows for a stronger *contract* (not coupling).
October 17th, 2006 at 4:10 ammiguel
You’re right Aral; it’s a nice idea. An interface is an abstract data type itself (and a class isn’t), so the event definition at interface level should be a feature.
October 17th, 2006 at 10:53 amdaniel yuen
good idea on that. but it also need to add a new type “event”, it that like .net’s delegate/event type?
October 18th, 2006 at 9:34 amaral
Hi Daniel: You’re right, it would need a new type for events. (I glossed over that in the example — taking it as a given.) I feel that this is natural for a system that is based on the event model.
October 18th, 2006 at 11:03 amktec
Would the compiler simply scan the implementing class for “at least one instance” of the event type declared in the interface?
Are we talking class level or method level, or both?
eg.
- methodA must dispatch an eventA
- classA must dispatch at least one eventA, eventB, eventC etc.
This is certainly an interesting idea, and would provide for the robustness enjoyed by the traditional observer pattern when using the EventDispatcher mixin. I really love the flexibilty of ED but I’ve often questioned its use in complicated applications over using get/set methods because i have no automated checking of event usage, so this really would solve the issue.
So how long till AS4 anyhows?
October 25th, 2006 at 11:42 ammorpheus
interface implementation should allow also property (get/set) definition, since they are a specialized form of method. if not, the whole point of property implementation in AS is lost in interfaces. if i could write:
interface ISomethingable
{
function get SomeString():String;
function set SomeString(val:String):Void;
}
it would simplify the interface a great deal to the consumer, since it could be casted to ISomethingable.SomeString for both operations.
November 7th, 2006 at 5:03 amDEBEDb
I was wondering, is there actually an official place for such feature requests?
December 19th, 2006 at 11:51 amLAlex
“I feel that this is natural for a system that is based on the event model”
I don’t really agree with that: the Flex/AS3 Framework is based on events, not the langage. :o) Implement this kind of feature into the langage because the framework developers decided to use the EventDispatcher mixin wouldn’t be a good thing for me…
Maybe a Metatag for that would help the IDE to propose the available event types.
The only way to specify event for now is to use the Observer model, and I think it’s not a bad way at all:
[as]package progress {
public interface ProgressListener {
function handleProgressEvent(e : ProgressEvent);
}
}
package progress {
public interface ProgressDispatcher {
function addProgressListener(lst : ProgressListener);
}
}[/as]
Some feature requests for my part:
- being able to specify constants in interfaces
- generics (typed arrays, dictionnaries, …)
- parametric polymorphism (overloading).
- be able to access variables to specify the [Bindable] metatag in FB2. If we want to save event type into static const, we’re still forced to use the plain string in those metatags…
DEBEDb: It’s already possible to specify getters/setters in interfaces with AS3… ;o)
January 3rd, 2007 at 6:52 pmaral
Hi LAlex,
I’m not disputing this. I’m saying that the language *should* be based on events. Or, in another way, that events should be made part of the language as they are central to development in Flash and Flex application. They are as important as objects and even more so than classes (which are, after all, still a stylistic element more than anything else in an *object*-oriented language).
January 3rd, 2007 at 8:37 pmLAlex
I agree that events are a really cool and a good way to have clean code, but the way AS (and ECMA) are oriented prevent to use them as a part of the langage, and it doesn’t seem to me that it’s a must-have: events are an implementation of a coding method, but that’s all…
But it’s true that the C# event management is pretty cool, maybe ECMA should think of it?
But I think it’s also an implementation, using operator overwritting…
^_^
January 4th, 2007 at 11:08 amAndrew Paul Simmons
AS4 or the next flash platform must render on the GPU. Silverlight is coming and the best way to win the battle is to blow them away before they get started. We must get some kind of interface to the GPU.
June 2nd, 2007 at 10:15 amPolaco
“AS4 or the next flash platform must render on the GPU”
Doing that maybe will compromise the flash player hardware independence since it will require certain GPU hardware to work. Maybe it could check if GPU acceleration is provided and if not use the CPU… just a thought.
There is a release date for AS4?
January 16th, 2008 at 4:24 pmI´m just getting my hands to AS3, I would be madness if this happens so soon and in my opinon it’s a bit unrespectful from Adobe to change the language so many times in a short period of time and a weakness of the product. It will be better for them to create a robust language and then provide new functionalties but not a new sintax/semantic.
Quvet
That feature will be available in AS5 only
January 23rd, 2008 at 4:07 amDarkrider
Maybe I’ve been slow to change but you guys are talking about AS4-AS5 like it’s some kind of a roll out phase. Dude heres an idea. how about the masterminds that come up with actionscript DO IT RIGHT THE FIRST TIME… YOU KNOW LIKE GOING TO THE MOON… YOU DO IT RIGHT THE FIRST TIME… I understand a programming language evolves over time but, this is starting to feel like a “High School Science Project” with Flash and Flex development. For starters the IDE in Flash and Flex doesn’t even compare to Visual Studio in logic and in grace, not to mention Error checking is a complete joke, and the intellisence works better in my email client than it does in Flash’s code view. So I have a great idea, how about we leave leave action script alone, and let the rest of the development community catch up. And focus on making the IDE better, more intuitive, take out the redundancy in the GUI vs Code.
March 15th, 2008 at 4:57 amDarkrider
Going to reply to my Extremely brash comments above. By saying I love Flash and I will defend it to the death The masterminds behind Flash/ActionScrip are doing a great job. But dude being someone who works in both Flash and Visual Studio, the reason Silver light is going to seriously hurt Flash and Flex isn’t because of the effectiveness of Action Script… it’s because of simple tools inside the Silver Light/Blend Visual Studio Development platforms like “Intellisense” and the Runtime Complier, not letting you compile jack chit’ unless the project works 100% without failure, or Seamless Database intergration you not only can create Database and populate it but you can make and a GridView to your project and animate it on screen. you can do all this in under 10 min…granted your using 3 programs to do it but the point is your using the same debugger you’d use in Silver Light that you’d use in Blend that you’d use in Visual Studio…
So again instead of pushing actionscript even further, Let all work on making the Development Environment Better an more intuitive, more integrated with all other Adobe Development Platforms… I think then we’ll start to see big holes in Interactive Development and Adobe Products, and then when Adobe fills those holes, we won’t have anything to worry about when Silver light start to take hold.
March 15th, 2008 at 5:27 amrob
Er… I just got off of a Silverlight project, using VisualStudio 2008 and I couldn’t disagree more. Granted, C# is a more robust language than AS3, but there were some major problems with application development. Perhaps you haven’t worked with with Flex before, but VS with Silverlight is dreadful in comparison. I found the error messages to be, at times, completely devoid of useful information. Intellisense is okay, however you run into some hurdles if you don’t already know the namespace of the class you want to use and already have it in the class since intellisense is completely ignorant of what is available. The dependency properties are obtuse and difficult to work with (intellisense is little help if any in this regard) and there isn’t a clear and robust way for you to communicate with the code behind from xaml. All this is made even worse by the horrific state of the documentation, which was useless half the time I tried to look something up. I certainly don’t think VisualStudio can boast any grace in comparison to FlexBuilder. Silverlight also seems to be more cumbersome at runtime, grinding through tasks which I have seen Flex perform efficiently. Silverlight seems to lean quite heavily on xaml, while punishing developers who try to do the same task in C#, resulting in thousands of lines of xaml code which, in addition to defining layout, which is the whole point of mark-up language, also defines functionality which can’t be efficiently ported to C#.
Silverlight is nice for .NET developers who want to get a taste of the front end, but it has a very long way to go until it is a desirable environment to develop in for people accustomed to Flex. ActionScript does need to be more robust, and Adobe is working on it, as they should. And don’t forget, there were a lot of baby steps on the way to the moon, which is a far better analogy to the development of ActionScript than I think you realize.
August 7th, 2008 at 7:22 pmJoshua
I would rather take FlashDevelop as a development environment than Visual Studio any day. Intellisense is not exclusive to Visual Studio.
August 26th, 2008 at 6:04 pm