Structure types

If you have read my post on function types in haxe you will know that the type-system in haXe is different to other languages like ActionScript 3 or Java. In haXe types are not bound to classes or interfaces, they are their own different “thing” and therefore allow more flexible typing scenarios.

One feature this type-systems allows are the so called structure types which can be used to type a variable to a subset of properties that the actual type contains. The simplest illustration is probably to define a variable with an anonymous object and let haXe figure out what type the variable has through type-inference.

var circle = { x: 100, y: 100, radius: 50 };
type(circle); // returns { y : Int, x : Int, radius : Int }

HaXe tells us that the type of “circle” is a structure type with three properties: x, y and radius which are all inferred to the type Int. So our variable became type-safe all of a sudden, which means we are not able to change the type of “circle” or one of it’s properties from now on:

var circle = { x: 100, y: 100, radius: 50 }

circle.x = 90; // will work fine
circle.y = "100"; // error: String should be Int

circle = { x: 90, y: 80, radius: 10 } // will work fine
circle = "circle"; // error: String should be { y : Int, x : Int, radius : Int }

To be clear: This is a good thing! If you don’t want automatic type-inference, you can always use Dynamic as type. Now that we know a little bit about the structure type we can also use them to type variables manually:

var circle: { x: Int, y: Int, radius: Int };
circle = {x: 10, y: 10, radius: 10};

Pretty simple so far, let’s investigate another useful case of structure types: polymorphism. In the beginning of this post we said that a structure type defines a subset of the actual properties of an object, which simply means that it doesn’t care about all the other properties. This makes it really easy to work with lots of different types that share a common subset, such as position coordinates x and y:

var circle: { x: Int, y: Int, radius: Int }  = { x: 10, y: 10, radius: 10 };
var rect: { x: Int, y: Int, width: Int, height: Int } = { x: 20, y: 20, width: 100, height: 100 };

function move( objectWithXAndY: { x: Int, y: Int } )
{
	objectWithXAndY.x += 5;
	objectWithXAndY.y += 5;
}

move( circle );
move( rect );

Of course you can apply this to objects that are instances of a class, like Point, as well:

var point: { x: Float, y: Float } = new Point(10,10);

One thing that you will have to keep in mind is that we need to type our variables “circle” and “rect” in the above example, as type-inference would type them to a constant type and that would not allow you to assign to another type with a subset of its properties. A little cheat-sheet explaining what works and what doesn’t:

var point: { x: Int, y: Int };
var	pointA3D: { x: Int, y: Int, z: Int } = { x:10, y:10, z:10 }; 
var	pointB3D = { x:10, y:10, z:10 };

point = pointA3D; // this works fine, as the type is set
point = pointB3D; // error: { z : Int, y : Int, x : Int } has extra field z
point = { x:10, y:10, z:10 }; // { z : Int, y : Int, x : Int } has extra field z

The “old” way

If you’re coming from ActionScript 3, or another statically typed language, you probably write a lot of static helper methods to manipulate native objects like String or Array. We do this because adding functionality to these types requires monkey-patching, like prototype in AS3, which is not always the preferred solution. For example when you want to delete or keep elements of an array based on a condition you would create a class like the following:

package org.devboy;

class ArrayUtils 
{

	public static function delete_if<T>( array: Array<T>, processor: T -> Bool ): Array<T>
	{
		var remove: Array<T> = [];
		for ( item in array )
			if ( processor(item) )
				remove.push( item );
		for ( item in remove )
			array.remove( item );
		return array;
	}

	public static function keep_if<T>( array: Array<T>, processor: T -> Bool ): Array<T>
	{
		var remove: Array<T> = [];
		for ( item in array )
			if ( !processor(item) )
				remove.push( item );
		for ( item in remove )
			array.remove( item );
		return array;
	}

}

You would then use the static methods of ArrayUtils to manipulate your arrays:

import org.devboy.ArrayUtils;		

var is_c = function(x) { return x == "c"; }

ArrayUtils.delete_if( [ "a", "b", "c" ], is_c ); // returns [ "a", "b" ]

Nothing wrong with that but let me show you a smarter and cleaner solution.

Extension methods

Extension methods are static methods, so no reason to change our static methods in the ArrayUtils class. The difference is that we can call extension methods as if they were instance methods which will result in much cleaner and more readable code. Let’s use our ArrayUtils example from above, but this time as extension method:

using org.devboy.ArrayUtils;		

var is_c = function(x) { return x == "c"; }

[ "a", "b", "c" ].delete_if( is_c ); // returns [ "a", "b" ]

Instead of import we used the “using” keyword to instruct the haXe compiler to make the static methods of ArrayUtils available as extension methods. Now we are able to call the “delete_if” method as if it was part of the Array class, but how does this work? Let’s compare the types of the static and instance method:

import org.devboy.ArrayUtils;
using org.devboy.ArrayUtils;
type( ArrayUtils.delete_if ); // Array<T> -> (T -> Bool) -> Array<T> 
type( [].delete_if ); // (T -> Bool) -> Array<T>

As you can see, the instance method is a subset of the static method because the first parameter has been partially applied to the instance it is called on. Therefore we can conclude that haXe  will provide you with an extension method when the type of your instance variable matches the type of the first parameter of your static method.

Use cases

It’s pretty obvious that using extension methods will allow you to build much cleaner APIs for you libraries and helper classes, just as if they were part of the original implementations.

You can also create ruby-like DSLs with extension methods like:

5.times( callback( trace, "Hello" ) ) //traces Hello 5 times

Let’s just dive into the first topic: partial function application! It might be useful to read up some background information on functions in haXe in a previous post.

Partial function application

In case you have never heard of partial (function) application, let’s have a look at what Wikipedia has to say about it:

In computer science, partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity. Given a function , we might fix (or ‘bind’) the first argument, producing a function of type . Evaluation of this function might be represented as fpartial(2,3). Note that the result of partial function application in this case is a function that takes two arguments.

This simply states that a partial function application is a subset of a regular function which has been partially applied, and I can guarantee that you are already using partial application, in some form, in your code today. Does the following look familiar?

function add( x: Float, y: Float ) {
	return x + y;
}

function addOne( x: Float ) {
	return add( 1, x );
}

The function “addOne” is actually a partial application of the function “add”.  It takes a parameter less than “add” and then applies 1 and the given parameter to “add”. Therefore “add” has been partially applied with 1.

In haXe there is no need to write these kind of functions by hand, a helper method called “callback” will generate them for you. Let’s redo the previous example, but this time with the help of “callback”.

function add( x: Float, y: Float ) {
	return x + y;
}

var addOne = callback( add, 1 );

addOne( 5 ); // returns 6

As you can see, this will save you from writing some code and at the same time it will also preserve type-safety. The “callback” method will also allow you to partially apply multiple parameters of your functions, it will apply them in the order they are defined in the function (read: left to right):

function sumOfFloats( x: Float, y: Float, z: Float ) {
	return x + y + z;
}

var addFloatToOneAndTwo = callback( sumOfFloats, 1, 2 );

addFloatToOneAndTwo( 5 ); // returns 8

Use cases

Partial function application can be very useful in a variety of cases. In functional programming they can actually be used to hold a state in situations where you don’t really need to create a class or value object to hold that state.

It will also be very useful when you need to pass a closure with only a subset of the parameters to a function, instead of doing the following:

function doMath( x: Float, y: Float, operation: Float -> Float -> Float ) {
	return operation( x, y );
}

function swapDivide( swap: Bool, x: Float, y: Float )  {
	return swap ? y / x : x / y;
}

doMath( 10, 2, function(x, y) { return swapDivide(true, x, y); } ); // returns 0.2

you can just replace the last line with this one:

doMath( 10, 2, callback( swapDivide, true ) ); // return 0.2

Notes

Please keep in mind that “partial application” gets mixed up a lot with “function currying”, also on the haXe mailing-list, but they are not the same. If you want to know what currying is you can read it up on Wikipedia.

I am wondering why the method to create a partially applied function is called “callback”, which implies that it is kind of an async process or function like a promise or future. Shouldn’t it instead be called “papply”?

The haXe type-system might be one of the biggest differences to ActionScript 3 whereas the rest of the language and especially it’s syntax is very similar. To fully understand function types in haXe we first have to cover some ground on the haXe type-system itself and it’s features like type inference.

Type inference

Type inference does actually exactly what it name says, if you’re not a native English speaker like me, let’s have a look at the meaning of “inference” in the dictionary:

inference |ˈinf(ə)rəns|

a conclusion reached on the basis of evidence and reasoning.

Applying this to our haXe code will mean that the type of a variable will be concluded on the basis of evidence, but what is the evidence in this case? Pretty simple, it’s the first value you assign to the variable.
Let’s have a look at some code:

var x; // type of x is Unknown
    x = "I'm a String"; // type of x is set to String	
    x = 1; // this will cause a compiler error as Int cannot be assigned to String

You can see that once you assign a value, the variables type is fixed to the type of the assigned value. This will save you some typing, especially for local variables, while in other languages like ActionScript 3 you would have to set the type manual for each variable.
Type inference is not mandatory, you can of course type your variables before you assign a value to them, just like in ActionScript:

var x: String; // type is now set to String
    x = "I'm a String"; // this will work
    x = 1; // this will cause an error

There are still a lot of use cases for setting types manually, like typing a variable to an interface.

Types will also be inferred for function parameters and return values:

function inferred(x) {
    return x;
}

inferred("abc"); // will take the string and return it
inferred(1); // will throw a compiler error because x is typed to String now 

Function types

Now that we know that haXe can infer the type of function parameters and return values, we can finally start talking about function types. As for type inference, parameter and return types are the building blocks of the type of a function, let’s have a look at a simple square function that takes a number and multiplies it by itself.

function square( x: Float ) {
    return x * x;
}

We’ve set the parameter “x” to the type Float, and the type of the return value will be inferred to Float as well. Let’s store it in a local variable and ask the haXe compiler for its type:

var square = function(x: Float) {
	return x * x; 
}

type(square); // type of square is Float -> Float

So the type is Float -> Float , let’s decipher this: The first Float is the parameter x and the second Float is the return value which is type inferred to Float. To make this a little clearer, let’s have a look at a function that takes two parameters:

var getStringXTimes = function(x: Int, string: String) {
	var result = "";
	for ( i in 0...x )
		result += string;
	return result; 
}

type(getStringXTimes); // Int -> String -> String

Now the type is Int -> String -> String  , which let’s us conclude that list of types seperated by -> contains of all parameter types and ends with the type of the return value.

This lets us now do something very useful, we can now set our variable to a certain function type, for example a type that taks an Int parameter an returns a Bool:

var biggerThan2: Int -> Bool = function(x) {
	return x > 2;
}

This will now give us compile time checking for function types, so no stumbling in the dark when it comes to passing functions around!

function doMath( x: Float, y: Float, mathOperation: Float -> Float -> Float ) {
	return mathOperation(x, y);
}

var addition = function(x: Float, y: Float) {
	return x + y;
}

var square = function(x: Float) {
	return x * x;
}

type( doMath ); // Float -> Float -> (Float -> Float -> Float) -> Float 

doMath( 1, 2, addition ); // will return 3
doMath( 1, 2, square ); // compiler error: Float -> Float should be Float -> Float -> Float

That’s just plain awesome! Isn’t it? We can now say goodbye to runtime errors!

Type parameters

As haxe has support for generics, you might want to type some of your parameters or the return value dynamically, depending on the type of a parameter. Let’s say we want to create a function that deletes items of an array based on the result of a function you pass as a parameter. Arrays in haXe are like Vectors in ActionScript 3, it can only contain items of a single type.
The first idea would be to just assign a dynamic type to your function parameters, like you would do in ActionScript 3 (Dynamic is equal to the * type in AS3):

function array_delete_if( array: Array<Dynamic>, processor: Dynamic-> Bool ):Array<Dynamic>
{
	for ( item in array )
		if ( processor(item) )
			array.remove( item );
	return array;
}

But this is not very useful as we are gonna loose compile time checking. For example when passing a function that takes an Int as parameter instead of the String that is in the array. But haXe wouldn’t be haXe if it wouldn’t provide us with a nice solution: We can add a type parameter to the function which will resolve the type of the values stored in the array, store it in the value T, which then can be used to describe the other types of the function parameters and return value.

With this we will get nice compile time checking for our function!

var ints = [1, 2, 3]
var strings = ["a", "bb", "ccc"];

var biggerThan1 = function(x:Int) {
	return x > 1;
}

var longerThan1 = function(x:String) {
	return x.length > 1;
}

function array_delete_if<T>( array: Array<T>, processor: T-> Bool ):Array<T>
{
	for ( item in array )
		if ( processor(item) )
			array.remove( item );
	return array;
}

array_delete_if(ints, biggerThan1); // [ 1 ]
array_delete_if(strings, longerThan1); // [ "a" ]

Session: The productive programmer

In our industry we always need to produce better, faster and cheaper. Therefore we always need to be on the hunt for better practices, processes and tools! That is where “the productive programmer” comes into play.

A productive programmer …

• … obeys the DRY principle: Don’t repeat yourself!
• … uses proven best practices and processes.
• … has the ability to choose the right tools for the job.
• … will create the right tool for the job if necessary.
• … will always question the way he works rather than blindly adhering to standards.

In the session we will shed some light on topics like automation, automatic code-generation, tool-building and test-driven development. We will also look into processes and methodologies from the enterprise as well as the indie-dev to pick the best from both worlds.

I hope that after this you’ll be a productive programmer too, or if you already are, an even more productive one!

What is buildr-hx?

Simply put, buildr-hx is a plugin for the buildr build-system to support haXe development. Buildr is an amazing tool to automate your compile, testing and deploy (and a lot more!) tasks and is not only feature-equivalent to build-systems like Ant or Maven but also provides you with a simple and clean API which makes it possible to describe even the most complex projects in a few lines of code. The ability to easily download 3rd-party libraries from Maven repositories makes it even more awesome!
There is a lot more to it, but I got to keep it short. Please check out the buildr project or the wiki-pages of my buildr-plugin for AS3 and Flex for more information.

 What is haxelib?

Haxelib is a command-line-tool to dowload and share haXe libraries via a central repository at lib.haxe.org. This makes it really easy to use a library like nodejs in your haXe projects, you first install the library with haxelib:

$ haxelib install nodejs 0.6

and then just tell the haXe compiler that you want to use it in your project:

$ haxe -lib nodejs:0.6

Uploading your own library is almost as simple, you just throw your source-code and a descriptor-file into a zip archive that you can upload to the haxelib repository:

$ haxelib submit myLibrary.zip

The descriptor-file, called haxelib.xml, contains all the necessary information about the library like: name, description, version and dependencies to other libraries. Furthermore you can also attach documentation or executable neko scripts to your library package.

So far, so good. A tool like this makes a developers life a lot easier and was really missing in the Flash & Flex space, even though it can be done with Maven, Ivy or Buildr and even though there have been several attempts to introduce this it never gained ground.

How can haxelib be improved?

Even though I am very enthusiastic about haxelib and really like the idea, I have experienced some issues and see some potential problems that could arise, especially in the context of multi-module projects or bigger teams of developers. Here I will list the issues I came across and will try to shed some light on their problems and possible improvements.

Modify the location of the local haxelib repository

By default haxelib will download libraries into a “global” directory, on OSX that would be: /usr/lib/haxe/lib/. Personally I do prefer to rather download the libraries into a directory under my home directory, so I tried to change the path of haxelib:

 $ haxelib setup ~/.haxe/lib

But this doesn’t work at all and fails with an error:

Please enter haxelib repository path with write access
Hit enter for default (/usr/lib/haxe/lib)
Failed to create directory '/Users/devboy/.haxe/lib' (std@sys_create_dir),
maybe you need appropriate user rights

This is not an issue with user rights, as I do of course have access to my home directory and also a sudo won’t help. It seems that haxelib doesn’t allow any custom paths to be used as repository locations, as I have tried several without success.
This is problematic because it doesn’t allow you to have multiple haxelib locations side by side which can be very useful in some cases. It also won’t allow you to have different haxelib setups for different users which can cause trouble when for example running a continous-integration system like jenkins on the same machine that you develop on. Basically any system where you need to have different configurations side by side!

[Edit]

As Nicolas Canasse pointed out in the comments, when first creating the directory by hand it will work. But still hope this will be fixed in a future version.

Haxelib install should also install haxelib zip archives

The haxelib install command will only install libraries hosted on lib.haxe.org and not library archives you have on you filesystem. You’re supposed to use the haxelib test command to install library archives into your local repository. This works fine, but in my opinion the name is misleading and it should be part of the install command.

Host your own haxelib server

The centralized repository  at lib.haxe.org is a great way to distribute open-source projects. But what about closed-source or internal projects within your company or team of developers?
We need a way to host our own repositories so we can leverage haxelib throughout the whole development process, not only for open-source!

Haxe compiler should accept haxelib zip archives as classpath

The haxe compiler does not allow for haxelib zip archives to be used as classpaths. This doesn’t seem to be an issue at first as you can just install them with haxelib and then use the -lib parameter of the compiler. But what if you don’t retrieve your libraries from lib.haxe.org? And what if you don’t want these libs to be installed into your local haxelib repository? You’ll always need to unpack the archive and point the compiler to it’s contents, which can be a tedious task even when automated.
The heart of the problem lies a little bit deeper: haXe does not have a library format similar to a JAR in Java or a SWC in AS3. Therefore it is not really possible to distribute haXe libraries in any other way than as source-code or via lib.haxe.org. It is essential to at least have the option to deploy a haXe library to, for example, a Maven repository, so it can be easily integrated into existing systems and workflows.
Actually a haxelib zip archive could easily work as a library format, and if either the haXe compiler or haxelib would provide a tool to easily create these archives, so they are all following the same convention, it should also be possible to use these libraries as classpaths in the compiler.

Haxelib non-interactive-modes for configuration

Who doesn’t like interactive-modes in command-line applications? I love them, it’s so much easier to walk through a dialog then having to remember all the correct parameters.
But what if it’s not a human that has to go through the dialog, what if you want to code against the command-line-interface?
I have this problem when trying to automate haXe unit-testing with buildr-hx and I need to provide it with some paths to be able to run the unit-tests, it’s a pain in the ass to try and step through a dialog like this via code, trying to parse stdin & stdout etc.
Always, I really mean always, provide a way to set all the values outside of a dialog!

Favor executables over haxelib run

When a haXe lib includes a neko run script, it can be executed via the haxelib run command, just like munit previously:

$ haxelib run munit

An idea would be to install an executable instead of  using haxelib run. That way haxelib could provide a powerful eco-system for (not only) command-line tools, just like Rubygems provides!
I know that you can use aliases to shortcut the command, but thats not quite the same.

Conclusion

Haxelib is a great tool, but to really prove effective for my daily workflow I would  need the improvements mentioned above. I am confident that this will happen in some way, as haXe development moves very quickly and user input seems to play an important role of feature development.
Please feel free to share this post and join a discussion in the comments!

 What build-system are you using?

Exactly 70% percent are not relying on any build-system at all and use the compile functionalities of their IDE’s (Flash Builder, Flash Pro, Flash Develop, etc.) instead. The Apache Ant build tool comes in second with 24 users. This accounts for more than 50% of the developers not using the integrated tools of their IDE. Maven, also maintained by Apache, is the build tool of choice for 8 developers. Let’s skip the others for now as a single user does not represent a user-base.

What build-system did you already use?

Ant is the most popular build-tool among developers as more than 80% already have experience with it. Maven comes in second, but is no close to Ant, with nearly 20%. Worth a mention under the follow-ups is Rake, a ruby based build-system. As project-sprouts also uses rake as build-tool we can add them together to 13 users which adds up to about 10% of all participants.

What build-system are you interested in using?

The 74 developers answering  ”None” in this question indicate that a little more than 50% are happy with their current setup. What about the other 50%? Maven seems to be the tool that most developers want to give a try in the future. Around 20% chose it. On second place is, which makes me really happy, buildr which supports ActionScript3 & Flex through the buildr-as3 plugin I developed. Almost as many votes go to Ant.

Conclusion

The first thing I noticed was that the majority of developers is not using any build-system at all. This made me wonder but also motivated me to write a blog-post on why you should use a build-system and what you and your team can gain from it. I will publish it here very soon.

Ant is by far the most popular build-tool out there, so if you want to make sure other developers can get started quickly you should go for Ant.

The Flex & Flash community is really missing out on some powerful features that project-oriented build-tools like Maven, Ivy or buildr provide. Dependency-management via public repositories for example is a really nice way to distribute you libraries and tools to other developers.

After all I am pleased to see that a few developers want to go and try out different systems which might make one tool gain more momentum in the future. But I doubt that anything will kick Ant from its throne anytime soon.

The survey has been closed.

I will publish the survey results in a following post, thanks to everyone who took part.

To get you started with the new features of buildr-as3, I’ll go through a simple step-by-step tutorial which will cover compilation, optimization, documentation and testing.

Step 1 – Installing or updating the buildr-as3 gem

If you have no previous installation of buildr or buildr-as3 installed, please follow the instructions on http://buildr.apache.org/installing.html and complete by installing the buildr-as3 gem:
In case you just need to update the buildr-as3 gem, you’ll be up and running after executing:
You should see output similar to this:

Step 2 – Creating a buildfile

Let’s get started with buildr! Before we start writing a buildfile let’s have a look at our project directory-structure:

“AdvancedExample” is the name of our project and it contains one module which is called “MyApplication”. When you’re working with eclipse you might translate project with workspace and module with project to get a better understanding of this setup.
Our module “MyApplication” contains a source folder in “src/main/as3” with just one file: “MyApplication.as”.
In order to compile this module we need to specify the module and its settings, such as compiler, main-file and other options, in our buildfile.
Let’s create a file called “buildfile” in our project-folder, like this:

Now let’s start writing some Ruby-code to define our build, first we are going to outline our project:

Now we need to make some settings for the compile-task:

Thats all we need to compile a simple ActionScript3 project into a swf, you now just need to go into the terminal:

Now we compiled a swf-file of our module, not to complicated was it?
Let’s move on to some more advanced stuff.

Step 3 – Optimize your swf-file with Apparat

I am sure you have heard of Apparat, the infamous framework by Joa Ebert to optimize the bytecode of your flash-application to gain some extra performance.
In case you never managed to get it running or integrate into your build don’t worry,
buildr-as3 will optimize your swf with just two additional lines of code:

This will execute TDSIafter your swf is compiled, the best is that you don’t need to call a special task! First we’ll have to clean the project to force a recompile:

Finally we can compile with Apparat. (Make sure Scala is installed and on your path)

There we go, now we got Apparat optimization every time we compile.

Step 4 – Unit Testing with FlexUnit4

In case you want to unit-test your code, buildr-as3 has an integration with flexunit4to make unit-testing as easy as possbile. To start testing we need to create our TestSuites and the flexunit4 TestRunner in the following directory structure:

Of course we need to let buildr know that we want to unit-test our code,
you need to change your buildfile to look like this:

To run the unit-tests with flexunit4 we just need to run:

Additional to the output in the terminal about the success or failure of the test, an html-page with the results will be generated by default.

I’ll stop here, knowing that I could have gone into much more detail about these features. I will cover the contents of this article in more depth in a screencast which i’ll do very soon. If you got further questions please feel free to use the comments, ask me on twitter or use the questions & answers page, thanks.

By the way: You can now find this example project on github.

You can run it in two different modes: LINEAR which runs from top to bottom and CIRCULAR which runs from center in against-the-clock rotation. I added a few rules mentioned by Stephen Wolfram which I found interesting, like Rule 30. Additionally I made up some rules myself.

I had some interesting results while playing around but unfortunately can’t reproduce them right now. Luckily i tweeted some screenshots here & here.

Play around with this basic automaton library, i’ll try to add more rules in the future.

Thanks go out to @soulwire for his SimpleGUI.