AIR UML tool : Working with types across different languages

One of the most obvious changes when switching between AS2 and AS3 is the difference in built-in types.

I'm talking Number vs int / uint. Void vs void.

From time to time I plan something that I want to execute in more than one language - in php5 or Actionscript 3 ... I've been fortunate to be able to leave AS2 behind but I know a lot of people are working on legacy projects.

With Colin Moock already talking about Actionscript 4, the focus for future-proofing seems to be on ECMAScript 4.

The release data for the new spec isn't til December 2008, but I'm guessing the end of the year will be upon us in no time.

Reading through the ECMAScript 4 Overview, it's struck me that building with this spec in mind will force us to include the kind of flexibility that will make it easier to extend this app to other languages.

For example - some of the Number types proposed - byte, int, uint, double and decimal - may not make it into the final spec, and we may continue to have the current AS3 set: int, uint and Number.

If each language contains a type mapping spec for the core types then AS3 can map byte, double and decimal to Number, and if AS4 supports them then they can be supported.

eg:

translations/as2/typeMapping.xml :

<typeMapping>
<type_byte>Number</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

translations/as3/typeMapping.xml :

<typeMapping>
<type_byte>uint</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>Number</type_double>
<type_decimal>Number</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

translations/as4/typeMapping.xml :

<typeMapping>
<type_byte>byte</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

So far, the types I can identify in the ECMAScript 4 list are:

null, undefined, void

Object

Number, byte, int, uint, double, decimal

Boolean, boolean

String, string

Array

Vector (a strictly typed array?)

Function

Map (binary relations)

Date

RegExp

Name, Namespace, NamespaceSet, NamespaceSetList

Error, EncodingError, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, UndefinedError, URIError

AnyString = (string,String)
AnyBoolean = (boolean,Boolean)
AnyNumber = (byte,int,uint,double,decimal,Number)
FloatNumber = (double,decimal)

XML, XMLList, AttributeName, AnyName

IterableType, IteratorType

I've also spotted a few more in the documentation - FieldIterator and ControlInspector perhaps?

Either way - this strategy allows us to be highly specific in our documentation, and then water that precision down for each language. Of course, coming back the other way it's trickier. Do we want reverse engineering to simply pick the most generic type, or do we need a special comment that can specify how types are backward translated? Something like ... (for AS3)

// *strictType:decimal //
public var salary:Number;

Obviously the app also needs to support types from your own library.

Something else I've noticed is the support for ! ? notation to specify that an object can / can't be null. Eg

// "!" indicates that v can't be assigned null
var v : MyType!

// "?" indicates that v can be assigned null
var v : MyType?

// "!" indicates that this whole class is non-nullable
class MyClass! { ...

The idea is that this will allow earlier detection of null-pointer errors - ideally at compile-time rather than run-time. That would make me very very happy!

----

It's a pain that ECMAScript 4 is still six and a bit months from completion, but I think the rigour that having to build for an almost-complete standard gives us is probably a good thing.