Standard library about haxe HOT 8 CLOSED

Initial implementation is done. All Haxe tests passed.

from haxe.

Array: not so good this way, see #32.

I don't know if you saw it, but I added @:phpGlobal metadata to genphp:
HaxeFoundation#5071
which I think is quite useful for handling global functions.

My idea for a php std lib was to take all the global functions (at least the most important ones) and generate externs for them with @:phpGlobal. Not sure about renaming some inconsistent function names, though. Also some functions that carry a resource around (like cURL) are good candidates for an abstract.

from haxe.

I've had a look at implementing Array. There's a lot of methods which can be inlined in the extern class. For example:

extern class Array<T> {

    var length(get, never) : Int;
    inline function get_length() : Int
        return untyped __call__('count', this);

    inline function concat( a : Array<T> ) : Array<T>
        return untyped __call__('array_merge', this, a);

    inline function join( sep : String ) : String
        return untyped __call__('implode', sep, this);

    inline function pop() : Null<T>
        return untyped __call__('array_pop', this);

    inline function push(x : T) : Int
        return untyped __call__('array_push', this, x);

    inline function shift() : Null<T>
        return untyped __call__('array_shift', this);

    inline function slice( pos : Int, ?end : Int ) : Array<T>
        return untyped __call__('array_slice', this, pos, end);
    ...
}

But then there's a few more methods which cannot be inlined and need a proper implementation. In other targets, which do not type it as a class, extra array methods are defined as static methods in another class. In python defined as python.internal.ArrayImpl and for JS as HxOverrides.

Defining the array as an abstract could work as well, but the typer refuses to accept that.

File "src/typing/typer.ml", line 5378, characters 2-8: Assertion failed

How would you like to handle these situations?

from haxe.

It would be great to inline Array methods because arrays used alot in almost any app. Could you please move your comment to a new issue to make sure your idea won't be lost?

from haxe.

I saw it, but i thought the purpose is to make any static function a global function. Which looked weird for me :)
But if it's for externs only, then it sounds like an interesting idea. Is there any difference between @:phpGlobal and an extern class with inlined implementations?
E.g.

extern class Preg {
  static inline function replace (haystack:Strimg, pattern:String, replacement:String) : String {
    return untyped __call__('preg_replace', pattern, replacement, haystack);
  }
}

from haxe.

It was meant for externs only because I got tired of writing this untyped __call__ stuff. Also untyped __call__ generates quite complex expressions for the compiler, it's not a real extern this way.

As far as I understood Simn is also not happy with these magic functions, they lead to quite a lot of problems. I don't know if the newer generators (python, lua) have other solutions for this.

from haxe.

I defined Superglobals like this:

@:phpGlobal
extern class Superglobal {
  @:native("_SERVER")
  static var SERVER:NativeArrayA<Dynamic>;
  ...
}

Not quite right, but you get the meaning.

from haxe.

Also I added some code to genphp for global constants, so that you can do e.g.:

@:phpGlobal
@:phpConstants("\\SOAP_SSL_METHOD_")
@:enum extern abstract SoapSslMethod(Int) {
  var TLS;
  var SSLv2;
  var SSLv3;
  var SSLv23;
}

Magic constants:

@:phpGlobal
@:phpConstants
extern class MagicConstant {
  @:native("__FUNCTION__")
  static var FUNCTION:String;
 ...
}

from haxe.