[haXe] haXe API extensions ?

Nicolas Cannasse ncannasse at motion-twin.com
Tue Mar 31 10:21:26 CEST 2009


Following the discussions about extending the base haXe classes, I have 
come up with an idea that might be implementable in haXe. It's kind of 
mixin that I'll try to explain below.

It's a bit hard to deal with custom extensions because the way OO often 
does it it through inheritance. But if you extend the List class for 
instance, all the libraries that creates/returns Lists will not create 
your extended List so it's quite inappropriate to use OO here.

One solution that we used while designing haXe standard library was to 
define standalone classes with several static fields, such as Lambda and 
StringTools or DateTools, which are a collection of optional additional 
methods for some basic classes.

The only issue with this scheme is syntactic, since instead of writing :

myString.trim();

you'll have to write

StringTools.trim(myString);

My proposal would be to add a new toplevel construct in haXe syntax (a 
bit similar to "import"), that would enable you to write myString.trim() 
while the compiler would actually understand that it means in fact 
StringTools.trim(myString);

Exemple :

package mypack;
extends StringTools; // or maybe another keyword

class Test {
	static function main() {
		trace( "hello".trim() );
	}
}

Since there is no "trim" method in the class String, the compiler would 
look at all the currently used "extensions" for it, and use the first 
that has a method "trim" that takes a "String" as the first parameter.

This should enable everybody to have its own custom extensions, and also 
since extensions needs to be explicitly used in files, would enable 
different and incompatible extensions to live together (as long as the 
classes names don't clash as always).

Nicolas




More information about the Haxe mailing list