[haXe] Optional parameters

[Nicolas Cannasse]

> The Action Script flash API often uses optional method parameters.  For 
> example String.substr has an optional length parameter.  However 
> std.String.substr in haXe is declared as:
>    function substr( pos : Int, len : Int ) : String;
> This suggests, that I am forced to come up with a value for len, even if 
> I just want to get the remainder of the string.  Of course, it's not a 
> big deal in this case but myString.substr(7) is prettier than 
> myString.substr(7, myString.length - 7) and there might be other places 
> in the API where it's more relevant.

Yes this is exact.
However right now in order to ease Flash development, all API inside the
flash.* package have all-parameters optional (just like AS2). The
problem of adapting existing AS API is then restricted to "core" classes
such as Array and String, and there is not so much problematic cases
right now.

Optional parameters and method overloading are actually often cited
features so I might have a look at it soon. However (in the case of
overloading) it's not an easy change, although I already made a proposal
that shows how it would work.

> As far as I can see, haXe does not support optional parameters.  I did, 
> however, manage to access the one-parameter version of substr by using:
>    var myString : String = "Hello world";
>    var sub : Int->String = untyped myString.substr;
>    trace(sub(5));
> This is hardly beautiful - are there any better ways to do it?

Reflect.callMethod(myString,myString.substr,[5])
This should work, but is not beautiful either.

> Another thing I discovered was that you can't mix proper methods into 
> extern class declarations.  Following the considerations above about 
> substr, I decided to add a single parameter substr-method to std/String.hx:
>    public function substr1(pos : Int) : String {
>      var sub : Int->String = untyped s.substr;
>      return sub(pos);
>    }
> This compiles fine but when I try:
>    trace("Hello world".substr1(5));
> I get an "undefined".  It seems  that when a class is declared "extern", 
> all methods are interpreted as declarations - even when they have a body 
> - and calling substr1 ends up trying to access a substr1 member in the 
> underlying flash class.  A little experimentation reveals that the body 
> is parsed but not typed and never reached.
> 
> I think proper methods would be nice to have in extern classes, ie. if 
> you need to do a bit of marshaling.

Extending extern classes is a bit problematic. It's done in some pretty
rare cases (Array.iterator() for example) but since you need to modify
the prototype of the class it's not possible right now to declare it
this way.

Such extensions should not be done by a person in particular, since they
make some changes in the base haXe APIs, and different people might come
up with different - incompatible - changes. That would cause some
trouble for all users. That's why I'm not sure if such extensions should
be accessible directly to the haXe user.

Nicolas