Is HashLink a static or dynamic target?

1

In many parts of the docs it mentions different performance attributes for dynamic or static targets. I had assumed that Hashlink was a dynamic target, but haxe’s wonky error messages seem to tell me otherwise sometimes telling me that certain things dont work in static targets.

So I was wondering does Hashlink count as a static or is it dynamic target?

2

If you try to assign null to an Int on hashlink, you get the message:

On static platforms, null can't be used as basic type Int

Plus it can be compiled to C/interops with C, so pretty safe to say it’s a static target. Is there something specific about the target that makes you think it’s dynamic? :thinking:

3

Well to be honest it was probably just an assumption, cheers for the info. :+1:

As a side note it seems though you can pass a null through functions here:

1 Like
4

Oh yeahhh, that’s weird. Maybe that works because Haxe as the “optional argument” feature someFunc(?test:Int), and Haxe maybe converts the null assign to an optional arg? Not sure tho, that’s definitely a weird inconsistency, I can understand your confusion XD

5

That was one of my few hurdles in getting code to run on Hashlink. Some functions accepting Int had to be changed to Null<Int>.

6

Hashlink was designed as a Static target replacement to dynamic Neko to achieve better speed and reliability. Hashlink is less mature than C++ target, it sometimes seems more strict and often has more rough edges. My limited experience is that HashLink and Cppia are sometimes less complete than c++ target although they are much faster to get a build.

Use Null<Int> if you need to set a variable to null.

someFunc( ?test: Null<Int> = null ) == someFunc( test: Null<Int> = null )

Noticable Neko is setup to be used on web but HashLink has not had these parts added, since I guess easier to find Node JS servers, and Neko Tora is fast anyway.

1 Like
7

I would suggest that your try is a minor bug, it should not let you assign null to Int directly.
maybe explore:

8

Optional functional arguments (regardless of syntax) always allow null values. You don’t have to type Null<>; the compiler adds that for you. Nor do you have to type = null.

This happens because the compiler uses null to indicate missing arguments. Even if there’s a non-null default value, the compiler will still use null, temporarily.

public static function someFunc(test:Int = 0):Void {
    //The compiler inserts this check at the beginning of the function:
    //if(test == null) test = 0;
    
    //With that done, you're guaranteed to have a non-null value.
    trace("test is " + test);
    
    //But `test` is still `Null<Int>`.
    test = null;
}

public static function main():Void {
    //If `test` is omitted, the compiler passes `null`.
    someFunc(); //test is 0
    
    //If you pass `null`, it works exactly the same.
    someFunc(null); //test is 0
    
    //If you pass a value, that works as normal.
    someFunc(1); //test is 1
}

Not a bug, just a quirk. Optional arguments wouldn’t work without it.

2 Likes