HaXe Language Nuances

From dis-Emi-A

Contents 1 Nuances / Dangers 2 Unusual 3 Limitations 4 Feature Requests

Nuances / Dangers

This is a list of the nuances found while using haXe. Some are annoying, and some are actually quite dangerous.

inline has semantic meaning 

inline is not like in C++, it is not guaranteed to be a safe operation and can change the semantic meaning of the code using it. It additionally changes the typing of the function which poses problems for inheritance and type inference. In some cases the use of inline can lead to runtime errors that would not have otherwise occurred.

fundamentals and null not platform independent 

fundamentals, like Int, are handled differently on some of the target platforms. One has to be aware of the target while programming and use them appropriately. This has an annoying impact on generics which may use fundamentals and non-fundamentals.

iterator behavior wrt remove is not clear 

Some iterators fail to operate correctly if an object is removed from the iterated collection. There is no clear description as what is to happen.

iterators are strictly duck-typed and not implementable 

This nuance means that you can't explicitly say you are implementing an iterator -- and benefit from quick compiler checking on correctness. The duck-typed nature is good, but the lack of strict iterator definition is slightly annoying.

typedef inferencing fails with inheritance 

Attempting to create and assign types with typedefs requires many cast operations.

language is loosely specified, often regression 

Since the language is loosely specified and faces many changes, there are often regressions which occur in the compiler. We try to keep our own language tests now, but occasionally new things come up.

closures require syntax hack to use current object 

The infamous "var me = this;" appears in any case where you need to use the current instance in a closure.

limited use variables in interfaces 

Variables in interfaces are good, but they are quite strict in that you cannot specify getters/setters for the variable in an implementation of that interface.

Unusual

irreducible error in MatrixUtil / possible typing problem 

In our seedFill class we have a redundant line "var q = sx" which if not present will result in runtime VerifyError 1068. I have been unable to reproduce via a smaller example.

Limitations

generics, not generalized parametric functions/class 

The generics system very closely models Java's and thus suffers all the same shortfalls, the most significant of which is the inability to call a static on the type, or to instantiate new objects of that type.

lack of string formatters 

Currently there is no equivalent to sprintf, <<, or php string expansion. Working with strings can thus be a chore.

lack of a Byte fundamental 

There is no haXe proper way of working with Binary data.

type inferencing is primarily RValue limited 

That is, it in general works like the proposed C++ "auto" keyword. In some cases the types of function parameters can be inferred, but in my experience this often leads to typing problems (in particular when inline is used).

no type overloading, no infix functions 

Thus simple operations on a Point class become very difficult to read

 var q = a.sub( c.mul( 3 ) )
 var q = a sub ( c mul 3 )
 var q = a - ( c * 3 )

collections library is weak 

Only a limited number of collections are available and the available functions is extremely limited.

Feature Requests

regex replace function 

replacing parts of a string with a regular expression is somewhat bulky and would be improved by having a callback mechanism as in PHP or Ruby.