HaxeFoundation / haxe

Haxe - The Cross-Platform Toolkit
https://haxe.org
6.2k stars 658 forks source link

does not have a constructor #11824

Closed nanjizal closed 1 week ago

nanjizal commented 1 week ago

Collating some libs into one and old code is breaking, the code concerned is trying to create a new abstract type over a structInit in a function, this used to work. Haxe version it seems to fail on: Haxe Compiler 5.0.0-alpha.1+1423a5f

public static inline
    function Float32Array_to4x4Transpose( arr: Float32Array ): Matrix4x4 {
        return new Matrix4x4( { a: arr[0],  b: arr[4],  c: arr[8],  d: arr[12]
                              , e: arr[1],  f: arr[5],  g: arr[9],  h: arr[13]
                              , i: arr[2],  j: arr[6],  k: arr[10], l: arr[14]
                              , m: arr[3],  n: arr[7],  o: arr[11], p: arr[15] } );
    }
fix is
    public static inline
    function Float32Array_to4x4Transpose( arr: Float32Array ): Matrix4x4 {
        final mat4x4:Mat4x4 = { a: arr[0],  b: arr[4],  c: arr[8],  d: arr[12]
            , e: arr[1],  f: arr[5],  g: arr[9],  h: arr[13]
            , i: arr[2],  j: arr[6],  k: arr[10], l: arr[14]
            , m: arr[3],  n: arr[7],  o: arr[11], p: arr[15] };
        final matrix4x4 = new Matrix4x4(mat4x4);
        return matrix4x4;
    }

the lib is https://github.com/nanjizal/geom that used to work. please let me know if you need more assistance with try haxe example, or if I need to use newer haxe, just have few frameworks setup so reluctant to change. Can provide more details if useful. 'does not have constructor' is a confusing error?

Many thanks.

kLabz commented 1 week ago

A try haxe would be nice indeed

nanjizal commented 1 week ago

ok I tried to build a try haxe... but not getting the error. Sorry Close this as it is not clear why the error, it maybe something else unless it is package related aspect. But certainly a cut down try seems to work.

//https://try.haxe.org/#714CeD08
import haxe.io.Float32Array;

function main() {
    trace("Haxe is great!");
    var fa32 = new Float32Array(2);
    fa32.set(0, 10.);
    fa32.set(1, 12.);
    var point = Conversion.Float32Array_PointType(fa32);
    trace(point);
}

@:structInit
class Point {
    public var x = 0.;
    public var y = 0.;
    public inline function new( x: Float, y: Float ){
        this.x = x;
        this.y = y;
    }
}

@:transient
@:forward
abstract PointType(Point) from Point to Point {
  public inline function new( p: Point ) { this = p; }
}

class Conversion {
    public static inline function Float32Array_PointType(arr:Float32Array):PointType {
        return new PointType({x: arr[0], y: arr[1]});
    }
}
nanjizal commented 1 week ago

( I am using dox to check I have rearranged and updated packages, but should be same as a try )

nanjizal commented 3 days ago

For anyone with a similar problem finding this in a search. When refactoring and moving lots of files round, it is not always ideal to use the haxe compiler with dox to pickup incorrect file paths used in say private 'access' import and packages if there are hundreds of minor path amends and lots of abstract types. So if an error seems odd and not correct it is viable the compiler is not able to resolve enough to provide the expected error and may give a message that seems misleading. Similar with porting large codebases, too many errors will mean you can't trust they will be all useful.

So in my case the solution was to test the refactored code in parts slowly and resolve and add any tweeks needed by the newer haxe version, getting a clean dox build before moving over more classes. Unfortunately I am not able to provide a cut down of where the compiler was being mislead and it is probably not something important. But since have more code to move, I am considering creating a terminal tool to change path references based on current file structures. Sorry if I wasted any of your time kLabz.