Future Language Features

This is a place to gather features that are being considered for future Haxe versions. Please don't add your own proposals here, they need first to be discussed on the Haxe mailing list.

Nothing here can be considered to be definitive until implemented in the compiler, you are then welcome to suggest improvements on the mailing list.

Properties Reflection Support

The idea is to add proper API (and runtime support) in the Type class in order to be able to list the properties of a given class, with its getter/setter methods.

SWC Input

Then ability to link one of several SWCs. This will replace --gen-hx-headers and provide better interoperability with Flex and other AS3 libraries.

The main issues to solve are the ability to override protected AS3 methods as well as native getter/setters, and to properly link several SWCs together, while including only the classes that are used.

The following features are required to implement them :

  • metadata support (to store protected, namespaces, etc)
  • mutiple --swf-lib

As for 2.07, most of these requirements has been matched, still needed it to allow SWC reading (currently on SWF input supported) and resolve dependencies to link the minimal used set of classes.

Literal Hashes

The ability to declare literal hash tables :

var x : Hash<String> = { hello => "World", "Welcome back" => "home" };

Haxe XML Format

The ability to output an XML representation of a fully typed Haxe program (after typing but before code generation), and the ability to also load such XML representation, in order to enable 3rd party tools to perform additional tasks before final compilation.

RTTI Changes

Currently only classes can implements haxe.rtti.Infos in order to get an extra static field __rtti which contains RTTI informations encoded as XML.

The idea is to enable any type to have rtti by using metadata syntax :

@rtti
enum E {
    ....
}

And to add a specific API to retrieve these RTTI informations :

var r = haxe.rtti.Infos.get(E);

It should also be possible to replace the current XML format by some native format by using directly Haxe data structures to construct the RTTI informations.

One possible extension for this feature is the ability to represent, at runtime, some types that cannot be represented currently, and thus cannot be checked (such as structures types).

However runtime checking of parametrized types is still quite hard to obtain.

Also, the Anonymous fields are not proper fields (in particular they don't have get/set accesseses) so this needs to be fixed.

Removal of Temporary Stack Objects

Thanks to inline, some objects no longer have methods actually called. But they still need to be allocated in order to be used. The idea is to optimize the following program :

var p = new Point(5,10);
return Math.sqrt(p.x * p.x + p.y * p.y); // inline version of ''p.length()''

into the following by moving Point member variables on the stack and inline the Point constructor code as well :

var p_x = 5, p_y = 10;
return Math.sqrt(p_x * p_x + p_y * p_y);

Anonymous type parameters contraint

Allow the following :

typedef Foo = { function foo() : Void; }

class A<T : Foo> {
}

Constraints in method parameters

Be able to do the following :

function foo<T:Float>( x : T, y : T ) {
    return x + y;
}

Abstract types

The ability to declare abstract types which are a good way to represent basic types which cannot really be considered classes or objects :

abstract Void;
abstract Float;
abstract Int > Float;
abstract UInt > Int < Int;
abstract Int32 < Int {
    public static function foo( v : Int32 ) {
    }
}
abstract Class<T> { .... move Type API here .... }
abstract Enum<T>{ ..... move Type API here .... }

There is an automatic "using" done on abstract types in case they have some static methods.

Package Changes

The idea is to group some common classes which are currently shared by Neko/Php/C++ : they have been separated since theses targets have been added incrementaly, but maybe should be group into a single package for all "system" languages.

Either haxe.sys or a new sys toplevel package.

Concerned classes are :

neko.Sys, neko.FileSystem, neko.db.*, neko.io.*, neko.net.Host, neko.net.Socket*, neko.zip.*

I guess such change needs appropriate thinking about package organization in Haxe, especially if we think about possible future mainstream targets such as Java and .NET

2.08 already have sys.db

Dropped Features

Dropped Features

version #11996, modified 2011-12-03 13:29:41 by ncannasse