[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