mikemo

ActionScript has several different ways to convert an object to a string, and figuring out which one to use can be confusing.  This post compares them, and tries to give you a deeper understanding of what is going on.

• String(myobj) almost always succeeds; may return "null" or "undefined".  This is usually the behavior you want.
• "" + myobj is effectively the same as String(myobj), so you can use this instead if you prefer.
• myobj.toString() calls the toString() member function -- in most cases this ends up being equivalent to String(myobj), but if myobj is null or undefined, myobj.toString() will throw an exception.
• myobj as String will return a string if myobj is a String, but will return null if myobj is of some other type.
• For objects of type XML or XMLList, don't forget about myobj.toXMLString().

String(myobj)

This is often the best choice.  If you don't remember anything else from this post, just remember that String(myobj) is the "safest" way to convert an object to a string.

Although String is a type, String() is also a function.  It isn't a constructor -- it is a regular function.  Its behavior is to take whatever argument you passed it, and convert it to a String.

This function will pretty much always succeed without throwing an exception.  The only case where it will throw an exception is the unlikely case that myobj.toString() gets called and that function throws an exception.

The behavior of String() is formally defined by section 9.8 of the ECMAScript spec.  (Note, this is confusing: When the ECMAScript spec refers to "ToString" or "[[ToString]]", they are not talking about the toString() function -- they are talking about the formal definition of what ECMAScript should do if it needs to convert any object to a string.)

The main thing to remember is that it will always return a string -- e.g. if myobj is null, String(myobj) will return the string "null", and if myobj is undefined, String(myobj) will return the string "undefined".  If myobj is a user-defined type, String() will end up calling its toString() function.

"" + myobj (or myobj + "")

This is functionally equivalent to String(myobj).  Because of the rules of ECMAScript's + operator, "" + myobj will result in String(myobj) being performed on the second argument, and then being concatenated with the empty string.  Concatenation with the empty string is very efficient in the Flash player, so don't worry about that.

myobj.toString()

This is fine for most cases -- it will work on numbers, booleans, user-defined objects, strings, etc. -- but if myobj is null or undefined, this will throw an exception. Explicitly saying myobj.toString() means you explicitly want to call the toString() member function of myobj, but if myobj is null or undefined, then of course it can't have any member functions. 

myobj as String

You won't use this very often. The "as" operator means, "If the object is already an instance of the specified type, then cast it to the specified type and return it; otherwise, return null."  So myobj as String will return myobj cast to a String if myobj is already a String, and will return null if myobj is any other type.  In most cases this is not the behavior you are looking for.

myobj.toXMLString()

Don't forget that if myobj is of type XML or XMLList, then String(myobj) and myobj.toString() will work, but may or may not give the result you wanted; you may want myobj.toXMLString() instead.  See part 5 of Common E4X Pitfalls.

I am excited to announce that Adobe, in its continuing efforts to port AIR to as many platforms as possible, has begun work on porting AIR to CP/M. Today I brought my beautiful old Osborne 1 in to the office to get started on the job.

The project is off to a slow start -- at this point, the computer still doesn't boot.

The Flex SDK is now open source. To whet your appetite and get your brain going on some of the possibilities that this opens up, here are a few tidbits of information:

• The trunk directory is where active development is taking place on Flex 4 (codename Gumbo). Start there if you want to track Flex 4, contribute patches, and so on.
• The 3.0.x directory is where Flex 3 is kept.  This is a stable branch that will only be changed if there are patches to Flex 3. Start there if you want to play with or modify the Flex 3 source.
• In the rest of the bullet points below, any directory I mention exists as a subdirectory of both the trunk and the 3.0.x branch.
• The entire source of the compiler is in there. This includes two main parts: mxmlc (in the modules/compiler directory) and asc (in the modules/asc directory). asc is the lower-level component that parses and compiles ActionScript source code; mxmlc is the higher-level component that parses MXML files, calls asc to have it compile ActionScript, hooks up binding, invokes the linker, and so on.
• One of the coolest parts is swfdump.  As Gordon explained, this gives you the ability to see exactly what is inside a swf. This is a great learning tool for understanding what really goes on in the compiler and in your own code. Try "swfdump -abc myapp.swf > myapp.txt", and then start exploring.
• The entire source for the command-line debugger, fdb, is all there, in modules/debugger. For the starting point of the command-line debugger, see DebugCLI.main(). For the entry point to the generic debugger API -- upon which both fdb and the Flex Builder debugger are built -- see Bootstrap.sessionManager().
• In the "development" directory, you will find Eclipse projects for most of the projects. There is no project there for asc, but there are projects for mxmlc, fdb, swfutils (which has the source of swfdump), and so on. The projects are divided into two groups: The "java" directory contains Eclipse JDT projects for the Java-based parts of the Flex SDK, such as the compiler and the debugger, and the "flex" directory has Flex Builder projects for the Flex-based parts of the SDK, such as the Flex framework. To use these, follow two steps: (1) in the preferences, in both General > Workspace > Linked Resources and Java > Build Path > Classpath Variables, set FLEX_SDK to point to the root directory of your SDK; (2) do File > Import, Existing Projects into Workspace.
• Flex Builder 3 supports not only Flex 2 and Flex 3, but, in fact, it supports any custom Flex build you care to make.  Drop in your own hacked compiler. Drop in your own hacked framework.swc. Drop in a patched flex-config.xml, and watch projects that use that SDK automatically pick up the changed library path. To make Flex Builder "see" your SDK, just go to the Eclipse Preferences, and then Flex > Installed Flex SDKs, then click "Add..." and point to your SDK's root directory.
• Don't forget that the entire Flex bug database is out there for you to see -- search for info on existing bugs, vote for bugs you want to see fixed, log bugs, suggest enhancements.