AS3 Enum preprocessor: progress report

AS3 EnumsRecently I have been working on an AIR-based project for an AS3 language preprocessor that adds enumeration (enum) support to the language. Today I’m releasing a web-based demo of the project. It can take an enum definition, parse it and either generate an AS3 “enum” class, or report an error if mistakes have been made in the source. The resultant code can then be imported into FlashBuilder etc, allowing the use of enums, rather than lists of numeric constants, in your code. Continue reading “AS3 Enum preprocessor: progress report”

AS3 static inheritance: developers beware! (revisited)

A while ago I wrote an article on the oddities of AS3 with regards to its lack of static inheritance. As part of my AS4 proposals series, I started writing a proposal for introducing static inheritance to AS4. In the process of writing it, I delved deeper into this topic and found that AS3 static inheritance is a truly strange beast indeed. It can be summed up neatly (though probably confusingly) as “for a class B that inherits from a class A, public static methods of A are inherited as protected static methods (which cannot be overridden) by class B” Continue reading “AS3 static inheritance: developers beware! (revisited)”

An AS3 language extension proposal: Java-style enums

Enumerations, or “enums”, are a handy language feature present in many programming languages. It’s what is often referred to as a syntactic sugar feature. What this means is that the behaviour of enums can be achieved using other language features, enums just simplify the process. To use another buzz-word, enums avoid developers having to write a lot of “boiler plate” code, ie code that is long-winded and repetitive and that is better suited to the compiler inferring or generating it for you. Not only does boiler-plate code waste a developer’s time, it encourages that developer taboo: copying and pasting. Copying and pasting of code is one of the greatest sources of bugs, and so anything that discourages it is a good thing. Unfortunately ActionScript 3 (AS3) lacks enums, so I’m proposing here a way of adding them to the language. Continue reading “An AS3 language extension proposal: Java-style enums”

ActionScript signals, events and interfaces

Signals is a great new ActionScript Framework which offers an alternative to Flex Events. Whilst it has a nice set of features that give it advantages over Flex events, there is one claimed benefit that I find difficult to accept. This selling point, popular with signals fans, is that an interface can specify a signal contract for classes implementing that interface. Continue reading “ActionScript signals, events and interfaces”

AS4 Feature proposal: Type inference

AS4 draftThis is the first in a series of articles I plan on creating addressing important features that I feel are missing from ActionScript 3. They are features that I’d like to see added to a future version of ActionScript, which I’ve assumed would be called ActionScript 4 (AS4).

This first article is on type inference. Continue reading “AS4 Feature proposal: Type inference”

Flex developer tip: initialising a datagrid with a sorted column

The Basic Datagrid
If you use Flex, then you are likely – sooner rather than later – to find yourself using the datagrid component. On the whole, it’s a really powerful and fairly easy to use component. There is one caveat to this though and that is the way column sorting occurs. Consider the following code:

This results in the following SWF:

As you can see, the data is presented in the datagrid in the same order as the code defines it. Click on one of the column headers and it sorts that column. Click again and it reverse sorts the column. This is great, unless you want the datagrid to start up with on of the columns sorted. That’s when the fun starts.

An Automatically Sorted Datagrid
If you read through the API documentation for the datagrid, it is really vague on how sorting occurs and there is no obvious way of initialising a datagrid in a sorted state. In the past, I have tried all sorts of ways of ways, including simulating a click event on the column header to force a sort and even creating a datagrid subclass that overrides a lot of the sort arrow placement code to force a sort arrow to appear at start up. Such techniques though are messy, unreliable and there was always this nagging feeling that I’d missed something obvious.

Recently I applied a bit of lateral thinking – and a lot of googling – to the problem and I discovered the proper way to solve this problem. It wasn’t obvious, but it was far simpler than anything else I’d tried and it works properly. The key to it is realising that when one clicks on a column header, a sort is applied to the data source and – this is the non obvious bit – that sort is used to determine where the sort arrow appears and whether its an up-pointing or down-pointing arrow. So the solution to having a datagrid start up in a sorted state is to apply a sort to the datagrid’s data source at start up. Told you it wasn’t obvious!

Consider therefore the new version of the code. The key part is the contents of start(), which is responsible for initialising the datagrid with a sort.

This results in the following SWF:

Applying a Compare Function to an Auto-Sort Datagrid
There is one final problem with initialising a datagrid in a sorted state and that is when columns have their own custom compare functions. When the titlebar is clicked, the custom function is applied to the sort. When we initialise the datagrid in a sorted state, we are supplying it with a presorted data source with a Sort object attached. Therefore the custom function is not applied. All is not lost though, as the function cane be manually attached to the Sort object. The following code demonstrates this with a function that sorts first the colour number, then the name for the red green and blue fields.

And the two-column sorting behaviour can be observed in the resultant SWF below:

And there you have it. Sorting a datagrid at start up may not be intuitive, but it’s fairly straighforward once you know how.

ActionScript 3 inheritance: developers beware!

Following on from my recent post regarding variable scope within ActionScript, I’m going to explain another “gotcha” that can catch out developers used to “proper” OO languages, such as C# and Java. That gotcha relates to class/ static member inheritance.

Consider the following C#/ Java code (ignoring package-level considerations, it will compile in either language):

With C# and Java, there is nothing spectacular about this code. Sadly though, achieving this functionality in ActionScript requires a significant work-around. If we simply rewrite the above using AS3 syntax, we get the following errors:

and this code won’t compile. Instead we get:

As the “Static properties not inherited” section of the language reference explains, AS3 doesn’t support static member inheritance, thus the errors. This limitation can be worked around with a rather ugly bodge. Modify ChildClass to the following:

and the errors go away. Having to do this for every class that inherits from a parent with static members though would be both tedious and unmaintainable. It is therefore probably more practical to simply accept this shortfall with the AS3 language and work with it, rather than fighting it.

As a final point, the scoping rules of AS3 cause a weird effect related to this issue. Consider the following version of ChildClass:

This code compiles just fine. Even though i and method aren’t accessible via ChildClass for code external to ChildClass, within that class, all parent and other ancestor static members are accessible.

ActionScript 3 variable scope: developers beware!

Consider, if you will, the following piece of non-language-specific code:

If you are a C#, Java, C++ etc developer, such a piece of code might look decidedly unspectacular. Not so with ActionScript 3 (AS3) though as I recently discovered.

The equivalent in AS3 would be:

and this code won’t compile. Instead it will report an error due to variable i being redefined as a different type. Further, if you change i in the first loop to be an int too, the compiler will then issue a warning that you are redefining i.

Being used to languages such as Java, C# and C++, I put this down to a compiler bug, disabled what I thought was a pointless warning message in my projects and carried on happy I’d hidden an annoying bug. How wrong I was. I recently discovered a bug in my code was due to a variable defined inside a loop changing the value of a variable of the same name at the method-scope level. It turns out that AS3 doesn’t support block-level scope for variables. Variables can only have one of three scopes:

  • Global
  • Class
  • Function

Whilst a function-level variable can override a class-level one, variables defined inside code blocks (such as loops, try blocks etc) have method-level scope.

The following code illustrates how AS3 variable scoping works:

Tracing through the code, I would have expected the following output:

The resultant SWF is included below. The results are really rather different:

The version of aVariable defined in go() is in scope from the start of the method, so label1 picks up its default value, rather than the class-scoped variable’s value. And the loop uses the same variable, so label4 is 4, rather than 2.

For more information on AS3 variable scoping, I refer you to the “Understanding variable scope” section of Adobe’s official AS3 language reference.

You can download a zip of the FlexBuilder project used to create the above SWF here.

Is it time to retire Java?

DukeYesterday, the boss and I took a trip up to London for Sun’s UK Developer Update event at the Royal Geographical Society. There was a “keynote” by James Gosling, followed by presentations on JavaFX, Java EE 6 and details of what is likely to be in Java SE 7.

Now I should make it clear that until recently, I regarded myself as a C# and ActionScript programmer. I’m new to Java. This isn’t strictly true, as I used Java back in its Java 1.1 days, but its changed so much since those days (and I’d forgotten most of it anyway), that in practice I’m a Java newbie. As a result, I naturally judge Java against C# (and to a far lesser extent, against ActionScript).

C# owes its existence to Java. Languages prior to Java may have had garbage collection, reference types rather than pointers, bytecodes, just-in-time compilation etc, but Java bought these technologies into the mainstream. As it came after Java, C# was able to adopt all the good points of Java, and scrap the bad stuff (the getter and setter mess of Java is replaced with elegant properties for example). Whether it did this successfully or not is a matter of opinion of course. From my point of therefore, Java automatically deserves respect, but it doesn’t deserve automatic authority. People grow old and wise, but also grow set in their ways. Programming languages appear to do the same.

Despite its seniority, Java has some clear advantages over C#. Breaking to labels is a glaring omission in C#, which Java has. C# requires the use of the evil-incarnate “goto” to simulate breaking to labels. Also the XML mess that is documentation comments in C# is pure farce compared with the simple elegance of Javadoc. Java has a whole raft of deficiencies though, and the two biggest ones are the lack of anonymous functions (let alone closures) and the lack of properties. Both have been proposed for Java 7, but – according to Sun’s presentation yesterday – neither will now appear. On a lesser note, Java 7 will not support operator overloading either, so string comparisons will remain using the grossly messy .equals() method to compare string value. This is a minor issue in comparison with properties and closures.

Why are anonymous functions/ closures and properties such a big deal? Both can be worked around in Java. Properties are after all just a neater way of doing getters and setters and people have come up with bodge simulations of delegates for Java. The big deal is that these are basic features of modern languages. Even the somewhat “noddy” scripting language, ActionScript, manages to implement both. Every other JVM-based language that I know of – JRuby, Jython, Groovy and Scala – all support closures.

Java is old and is becoming set in its ways. Language developers always run into problems with balancing feature advancements with avoiding breaking legacy code and Java is no exception. Perhaps we need to accept that closures and properties will never come to Java as it is just too difficult to implement both neatly, without breaking backward compatibility in too big a way. If this is the case, then perhaps Java 7 should be the last version of Java and it ought to be retired and replaced with a younger, more adaptable language.Whether the growth in alternative JVM languages is a sign that people are already moving on from Java to newer languages is difficult to judge. JRuby, Jython, Groovy and Scala are all dynamic languages. Dynamic languages have seen a general resurgence in popularity recently. What is needed though is a static language replacement to Java. One that can seamlessly interact with legacy Java code, whilst supporting modern programming principles such as closures, operator overloading, properties etc, along with support for dynamic types (without being inherently dynamic), functional language principals such as currying and lambda expressions.

The more astute of you may spot where I’m heading here. Just as C# was born of Java, so perhaps we need a new version of Java, born of C#. Being a English tea addict, who is pretty indifferent to coffee, I propose (not very seriously) that we call it Lapsang. C# itself is starting to get old, and many of the new features – such as extension methods – have been implemented in an inelegant manner to avoid the backward compatibility issues that new keywords bring. So just as C# took Java’s good bits and added more of its own, Lapsang could take C#’s good bits, add a few new bits of its own (build concurrency into the core of the language for example) and give the JVM another 10+ years of life.

Java proberly is a dying language and it risks taking the JVM with it. If Sun (or IBM perhaps, if they buy Sun) bite the bullet and retire it as the prime JVM language, then there is no reason why the JVM cannot thrive and grow for many more years.

Twitter-based AS3 competition

flash_csGrant Skinner has organised a fascinating competition via twitter. The idea is to write an AS3 “program” up to 140 characters long that you then post on twitter, which gets automatically compiled and made available here. You get a “free” 140 character long piece of wrapper code around yours and the aim is to create the the most popular/ cleverest/ prettiest SWF. My favourite example so far is this one by Zach Archer. By moving the mouse around, you can create so really nice spinning patterns.

Most of the examples so far remind me a bit of ZX Spectrum loading screens, but it’s still clever what some people can achieve in just 140 characters.

The winner of the first round will be announced in a couple of days and will win themselves a copy of Flash CS4.