A Conversation with James Ward, Part I

---

Frank Sommers: What is ActionScript?

James Ward: ActionScript 3 is our implementation of the ECMAScript 262, Revision 4 standard. That's the same standard JavaScript 2.0 will be based on, once browsers officially support that version of JavaScript.

We've done a few things differently from the ECMAScript standard, and the reason for that was that the standard wasn't actually finalized when we built Flash 9 and Flex 2. We had to make some assumptions about what things would be in the spec before the spec was ratified by the ECMAScript standards committee. As a result, there are probably a few slight variances between what we implemented in ActionScript 3 and the final ECMAScript specification, which, I believe, is still not final yet.

Frank Sommers: What will surprise a Java developer the most when first encountering ActionScript 3 code? James Ward: Java developers will recognize and get to know the ActionScript 3 language very quickly. The syntax is very similar to Java's, and there are all the object-oriented features you're familiar from Java, such as extending classes and implementing interfaces.

The similar syntax allows Java developers to very quickly come up to speed by not having to really learn a brand new language. They can just focus on learning the slight differences from Java syntax, and learn how to actually use the ActionScript 3 language within the context of the Flash Virtual Machine.

One of the biggest differences from Java is optional static typing in ActionScript 3. When I came from Java to Flex, I was struck by the fact that I didn't have to type everything. I could type things, when I felt that typing was important, and when I wanted code hinting in the IDE, and compile and runtime type checking, but then there were places when typing didn't matter so much. There are places when you can leave things untyped or, to put it differently, dynamically typed. Optional typing made me have to do a bit of a mental shift from how I, as a typical Java developer, really saw languages.

There are just a few differences in syntax from Java. The package declaration is almost the same, with the one difference that we put curly braces inside the package keyword, so when you define a class, the class definition goes inside the curly braces within the package declaration. Your import statements go inside that same block.

Instead of declaring methods, you explicitly have to say that something is a function, with the function keyword, and your function's return types are specified with a colon after the function name. Variables are defined with the var keyword, followed by the variable name, and then the type of the variable, if you want to specify a variable type.

ActionScript has very similar namespaces to Java's: private, public, protected. If you don't want something to be public, private, or protected, and want instead to have your own name space that you can use internally, you can define that namespace as well. If you have a variable, or an inner class, for instance, that you only want to be accessed from, say, just two other classes, then you can create a custom namespace and use that namespace in just those two classes. That gives you more flexibility in how you can structure your code. You can apply private, public, protected, or any other name space you create, on your class or a variable or a function. It's a bit different from how you'd do that in Java, but once you get the hang of it, you can get used to it and find it quite useful.

The Flex framework uses this technique pretty heavily. We have an mx_internal namespace that we use for variables that we think could change in the future and that you shouldn't rely on. But if you did want to get access to one of these variables, you could import the mx_internal namespace, and then have access to the variables in that namespace. By default, users don't see those variables.

Frank Sommers: What are some features Java has that ActionScript doesn't offer? James Ward: A lot of the new features that were added in Java 5 aren't available in ActionScript yet: generics and annotations, for instance. Other than those, just about all the normal object-oriented Java features that you'd expect are there. And ActionScript 3 has features that Java might have in the future. For all intents and purposes, for example, ActionScript 3 has a closures-like mechanism. Frank Sommers: Does ActionScript 3 support JavaScript's functional language features? James Ward: The functional aspects of ActionScript 3 are very similar to JavaScript's. We do have a top-level object called Function. You can define functions inline, for instance, for callbacks.

When you specify functions, a lot of times you may want to pull them out and use them as closure functions, and that's also available. Often, when you specify a listener in ActionScript 3, you would pass a function as the listener, which, in turn, will pass a reference to that function.

In ActionScript 3, you can do prototype-based classes, just as you can in JavaScript. In Flex, we hide that because we prefer the other style of object-orientedness: creating classes and extending them in the typical Java-like way. If you wanted to, you could get to the prototype stuff, and still do things through the prototype, though.

Other than the optional static typing, the only major difference between JavaScript in the browser and Flex's ActionScript 3, is the DOM that each language is implemented against. In the browser, the DOM is the browser's DOM, while Flex makes a different DOM available to you, that of the Flash Player. If you take the DOM differences out of the equation, then the languages are almost completely portable. I actually have taken a JavaScript library, a few thousand lines of JavaScript, and copied and pasted that into Flex. With a few minor changes, I was able to get that API running as an ActionScript 3 Flex API.

Optional Static Typing

Frank Sommers: I thought that static typing was an either/or proposition: You either had it, or you didn't. How does optional static typing work in practice? James Ward: Optional static typing means you can just mix and match: You can have a variable that is of type String, and the next variable can be dynamically typed. The Flex compiler will give you a warning, but the code will still compile and run just fine.

There are also keywords like is and as that allow you to do casting on objects. If you wanted to find out what type an object really was, you can do that through those keywords. In a function call, for instance, you may not want to require a specific type, but inside the function implementation you may want different logic based on what type you were getting. In that case, you can find out the object's specific type.

One of the places where you see the benefits of optional static typing is when you start pulling in Web services data that isn't SOAP, but come from RESTful or JSON-style Web services. You could go through all the work to type the whole response and convert everything into typed objects. But a lot of times the interfaces of the Web services that you're talking to aren't themselves very statically typed. Those interfaces don't necessarily follow a consistent object model.

That's one place where I typically don't force my objects into being statically typed. When you talk to the Flikr API, for instance, and you decided to define a bunch of objects that represent their API, if Flikr changes the data their API exposes, you would have to change your object model, too. Static typing may not buy you much in that case. With dynamic typing, as long as they used the same names, everything would continue to work.

Flex takes advantage of optional static tying in a couple of places. Flex defines an HTTP Service, for instance. [Editor's note: The HTTP Service is an object-oriented client-side HTTP API.] You can get back your response from the HTTP Service in a couple of different ways. The default way is to take all the XML you get back from a RESTful service call, and deserialize that response into basic objects: not typed objects, but objects that are basically just hashmaps or name-value pairs. You can also have the HTTP service give you back E4X objects, which is ActionScript's XML API. You can then execute XPath-style queries on that response, for instance. And you can also write your own custom deserializer to go through the XML tree and deserialize that into typed ActionScript objects.

One way to think about optional static typing is by comparing it to untyped Java collections. You can stick any type object into a collection, and then cast that object back into its type when you need to know the specific object type.

In Flex, if you define a variable to be of type Object, then you can set any property you want on that object. You don't have to specify in advance the properties of that object, but can, instead, go in and arbitrarily set properties on the object. If you create an instance of an object foo, you can just say, foo.name = "a new String". That would set the name property on that object, even though you never defined a name property for that object before. You can also add functions to an object in a similar way: You can just say, foo.doSomething = something, where something is a specification of a function.

XML as a Native Type

Frank Sommers: You mentioned E4X, ActionScript's native XML support. What advantages does E4X provide over other XML processing APIs?

James Ward: XML is a native data type in ActionScript 3. One way we support XML is through E4X, which is an ECMA standard, and is part of the ECMAScript language. We chose to follow the standard instead of creating our own XML support in the language. E4X is an XQuery- and XPath-like language for manipulating XML structures. The query language built into E4X makes it easy to find elements, or collections of elements, in your XML tree, pull elements out, or set and add elements to XML structures.

ActionScript, and Flex, also have facilities to take ActionScript objects and serialize them into XML and back. While E4X is very powerful and convenient for many XML-related tasks, you have the choice of whether to deal with XML objects, or whether to serialize XML objects into your ActionScript objects, and then use those ActionScript objects in your code. Those with a Java background may find the latter more natural. But once you get used to E4X, you may find it very convenient, too.

The Flex API

Frank Sommers: I'd like to turn from core language features to the ActionScript and Flex APIs. What similarities and differences will a Java developer find when working with the Flex APIs? James Ward: To give you a bit of a background, the Flex framework is a bunch of classes that help you build rich-client applications on top of the underlying ActionScript implementations. Flex allows you to use those ActionScript classes, and it compiles the ActionScript into bytecode that then runs within the Flash Virtual Machine.

The Flex framework classes define the containers, layouts, and controls, and are all implemented in ActionScript. The source code for the whole Flex framework is shipped with the Flex SDK. You can go in and see how all of those components are built, and you can extend those components as well with ActionScript code.

It's also possible to not use anything that Flex provides, and just build from scratch your own ActionScript rich-client framework. You could conceivably build anything you'd want on top of the Flash Player DOM, using Flash Player's ability to draw lines, do vector graphics, and use all the things that the Flash VM can do. All the Flash animations you see people do on the Web are built to run on the Flash VM, so you can conceivably go in and use the low-level drawing APIs to create animations, draw lines with nice anti-aliasing, display and record video, and so on.

But you don't have to do that, because Flex gives you all the components built for you, including very rich UI controls, such as a data grid. In your application, you can just create an instance of the data grid, for example, and then you can override any of the methods in that component, including default styles and properties.

The Flex components use the low-level Flash API to draw lines, and basically take advantage of the rich media capabilities of the Flash VM. With the Flex API, you're programming at a higher level, and don't have to learn the low-level details of how the components and effects are actually implemented.

At the same time, one difference from Swing, for instance, is that with Flex you could go really low-level, if you wanted to, because those low-level Flash API calls are available to any Flex application. You could even mix high-level Flex API calls with low-level Flash API calls. If you didn't like how something looked in Flex, you could go in and do some lower-level graphics calls to change how a component looked. You could also use that technique to set custom item renderers, too. In practice, you will very rarely, if ever, need to do that because Flex exposes a very rich set of component properties.

The other differences from Java come from the media-handling capabilities of the Flash VM, such as video and audio playback capabilities. Media support has been built into the Flash player for a long time now, and that's one of the areas where the Flash VM really shines. Flash was built with the idea to allow people to create multimedia experiences on the Web. Flex applications can easily take advantage of all those rich-media capabilities.

Video and audio integration with the Flex API is very simple and straightforward. If you wanted to have your Web cam record some video and broadcast that video out to other computers, that takes only a few lines of code to accomplish in Flex. You just find the Camera object in the API, and call a few methods on that object. Playing back video is similarly simple: You can use the VideoDisplay object, and point that to a URL. Out of the box, we support the FLV format, which is Flash Video, the SWF format, which is the regular Flash format,

Resources

Adobe's Flex SDK
http://www.adobe.com/products/flex/

An online Flex compiler
http://try.flex.org

Flex.org, the Flex community site
http://www.flex.org

A Flex component explorer
http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html

The ECMAScript4XML (E4X) Specification
http://www.ecma-international.org/publications/standards/Ecma-357.htm

The Mozilla ECMAScript 4 Proposal
http://www.mozilla.org/js/language/es4

Talk back!

Have an opinion? Readers have already posted 9 comments about this article. Why not add yours?

About the author

Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.