Standard library

[RealyUniqueName]

Crossplatform API of Haxe std lib.

php package in Haxe std lib API

• Native arrays
• Native regular expressions
• Predefined interfaces
• Predefined variables and superglobals
• cURL
• Predefined exceptions
• Some of predefined constants
• Externs for all standart PHP extensions (as haxelib package, perhaps)

[benmerckx]

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?

[RealyUniqueName]

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?

[mockey]

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.

[RealyUniqueName]

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);
  }
}

[mockey]

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.

[mockey]

I defined Superglobals like this:

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

Not quite right, but you get the meaning.

[mockey]

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;
 ...
}

[RealyUniqueName]

Initial implementation is done. All Haxe tests passed.