self conscious white noise

I recently gave a presentation on haXe at the Strands offices in Corvallis and Seattle.  I think it raised a few eyebrows, but probably ended up raising more questions than it answered.  This was to be expected, as haXe is pretty unique in its ability to target multiple web-related platforms.  The devil is in the details, and so I thought it was best to post everything here on the blog so that interested individuals can go over the specifics in a more involved way.

The demo that I showed was actually two parts: A simple “hello world” trace example, which I compile to  swf, php, and javascript.  Then, a more complex example that compiles some code to each of those targets, and then uses conditional compilation to build a web page that displays output from each target all at once (The PHP target references the javascript source, a javascript method references the swf file).

This, to me, is perhaps the most satisfying aspect of haXe:  The ability to treat each target as a minor variation of an API, rather than as a set of totally unrelated platforms.  Developing, targetting, and displaying results simultaneously is a strange feeling.  All of a sudden, javascript, php, and swf are operating off of the same script, and you are totally in control.

You can download the source as an archive here, or browse the source here.  Once you compile the Demo2 file, you should see something like this.

There’s a README in the source that’ll explain what’s going on.

If you’re totally new to haXe, you’ll want to download the compiler from the haxe.org download page.  After installing, you can run the build1.hxml – build4.hxml examples by simply typing in:

haxe build1.hxml

For each of the build files.  For the build.hxml file (non-numbered), you will need to edit it so that it points and outputs to a working web folder.  If you use TextMate, you can download the textmate bundle for haXe, and use the editor to browse and build files.

Nicolas just added a new keyword to the haXe compiler called “using”.  In short, this keyword lets you inject additional methods into instances of types.

“using” explained

The haXe “using” keyword  is a special import command for classes.   The command will import the given class normally.  However, it has special behavior if the imported class has any static functions accepting an argument.

The “using” keyword takes any static functions defined in the class, and adds those static methods to the argument type, as if the argument type defined the method itself.  In this sense, it behaves like a sort of implicit mixin, or trait.  However, it’s also very different from these approaches, and to the best of my knowledge, nothing like this exists in any other language.

Explaining what’s happening in simple prose is actually a bit cumbersome, so here’s some example code.  First, we’ll give a simple haXe example without “using”.  The first class is a Demo class that contains the main function:

// in Demo.hx
class Demo{

public static function main(): Void
{
trace(BarStringClass.addBar('foo'));
}

}

The second is a class that contains additional methods:

//in BarStringClass.hx
class BarStringClass{
public static function addBar(str:String) :String
{
return str + ' bar';
}
}

If we compile the code using main() from Demo, we’ll get “foo bar”.  We’re simply using the static class from BarStringClass to process the string and tracing it.  Pretty simple.

Now let’s look at what we can do to Demo.hx with “using”.  We’ll use the same BarStringClass from before, but we’ll change Demo slightly:

//in Demo.hx
using BarStringClass; // here's the 'using' keyword in use
class Demo{

public static function main(): Void
{
trace('foo'.addBar());
}

}

haXe now lets us access BarStringClass static functions as if they were functions of the String class.  In this fashion, the standard base classes can be augmented with additional methods without the need to extend them explicitly.

Notice how in this example it wasn’t even necessary to specify the “str:String” argument required by addBar(). When the haXe compiler injects the methods from BarStringClass, it will automatically fill in the current instance as the first argument… turning BarStringClass.addBar(‘foo’) into ‘foo’.addBar().  All of the first argument Types of the “using” classes will be augmented in this way.

So in this case, BarStringClass had one static function (addBar), and the first argument type was String.  Therefore, every String instance now gets the addBar() function.  You could have many different Static functions in a “using” class, and each of the first argument classes will get injected in the same way.

“using” with types and/or classes

The other nice thing about this approach is that it works with the more broadly defined Types/typedefs, and not just Classes. So, my IterTools functions that work (mainly) with Iterable Types can be injected with “using”, and then you can do things like:

for ( i in [1,2,3,4].cycle(5) ){
trace(i);
}

…to iterate through the numbers 1 through 4 five times. “cycle()” and the rest of the functions that operate on Iterables would also then work with Lists, FastLists, Hashes, and so forth.  When you add “using IterTools;” at the top of a class file, anything that can iterate can now “cycle()”.

Caveats

There are two significant caveats with “using”.  The first is that the injected methods are not available through reflection.  This means they’re not part of the “run-time” class instance.  The second caveat is that it can be very easy to overload several instances of a single method name (from multiple “using” classes).  Currently, haXe’s behavior is to only use the first matching static method from a “using” class.

“using” can be habit forming

Some of the positives to the “using” keyword approach are:

1. You can manage classes externally from code that defines them, seamlessly adding in functionality by augmenting classes and typedefs.
2. Anything you can do through the “using” keyword can be done by using static classes, so there is very little ‘magic’ going on… just some clever reformatting of function calls.
3. There’s a ton of static classes out there (in addition to my own) that already contain a lot of good practical functionality.  You can easily reuse these classes as “using” classes, or write your own that handle specific needs.
4. Method completion works with –display.  So once you include the “using” keyword with an appropriate class, you can instantly see the extra available methods by triggering a code-completion request inside your editor (assuming the editor does –display code completion).

I’m assuming “using” will be added in the next version of haXe (2.04).  Till then, you can play around with it by downloading and building from the CVS sources.

7/26 Update: “using” is now officially part of haXe (2.04).

My previous article talked a bit about Perl’s new “roles” method for managing typing.  In the article, I tried to address some of the criticism levied against duck typing, and in doing so perhaps misrepresented Perl Roles as being “rigid”.

Another blogger by the name of Sam Crawley gives an overview of the way that roles provide more flexibility in a recent post, however there is still a significant difference in approaches.

Duck Typing and Reflection

In both the original post on duck types and Perl Roles, as well as Sam’s rebuttal of my previous article, there is mention of the “can” method.  This method is used like:

$dog_or_tree->can( 'bark' ); 

This method tests to see if an object has the requisite field (presumably so that you can call a corresponding method, or access a property), and is very similar to the intent of duck typing.  However, it’s important to note that using this “can” method is not the same as duck typing.  The method is actually what’s known as a runtime class reflection, and not a compile-time type check.  This is an important distinction, because  true duck-typing will make the compiler check the types once before compilation, while reflection requires that the types be checked every time the code is run.  On many platforms (VM’s such as Adobe’s AVM2) reflection calls are quite slow, and should be avoided.

It seems that both authors are conflating these approaches, and unfairly criticizing duck typing for the inefficiencies of managing types through reflection:

If you want to get stricter, and if your language supports this, you can even check the arity or types of the allowed signatures of the method — but look at all of the boilerplate code you have to write to make this work. That’s also code to check only a single method.

You don’t need to insert “boilerplate code” in your classes for conventional duck typing approaches.  You write one “typedef” of required methods, as in a haXe example:

typedef Duck ={
   function walks(location:Position, direction:Vector<Float>):Waddle<Step>;
   function talks(say:String):Quack<Sound>;
}

And typically put it somewhere in your compiler class path.  Now you can accept “Ducks” as arguments anywhere, and they can be checked by the compiler.  From a typedef, we can assert that the Duck walks and talks appropriately (producing “Waddle” and “Quack” collections of “Steps” and “Sounds”).  The arity, return, and argument types let us describe the behavior in great detail.  The level of discrimination that is available only depends on the specificity of the classes, and any duck type assertions occur externally to class specific code.  After we write our Main classes, and create the Duck typedef, we could perhaps differentiate between different ducks, such as those that “molt() : Void”, and we wouldn’t need to update any existing class code outside of creating a new typedef:

typedef MoltingDuck = {
     > Duck,
     function molt():Void
}

Now we can make sure we’re dealing with molting ducks, that behave exactly like ducks in every other way.

Roles vs. Duck Typing, revisited

However, for a final comparison of Roles and Duck Typing, it is perhaps fair to say that Roles are more powerful in a sense.  Roles actually cover a lot of ground, it’s just different ground than what Duck Typing covers.  Roles encompass two major forms of class specification:  interfaces and mixins. The former lets you define methods and properties that must be implemented by the host class, while the latter define methods and properties that are implemented by the Role itself (the methods are specified in the Role description)  In this way, you can even use Roles as building blocks for class functionality in lieu of inheritance.  It seems that this is a pretty revolutionary way to approach OOP, so more power to them.

However, the  type checking performed by Roles is more rigid and structured than duck typing, at least in terms of what happens at the compiler level. You still must declare a Role inside of a class description (a la interfaces) for compile time checking.  For interpreted languages, it may not be that important to distinguish between type checking that occurs at the compiler vs. the checks that occur at run-time.  However, this distinction can be very important for other languages.

I can appreciate the need for articles to promote the idea of Roles within and without the Perl community, but I think it can also be done without unfairly criticising other approaches.  Despite the inaccuracies, the discussion of Roles has gotten me interested in Perl again, and nothing else has done that in years.