I don"t know how practical that would be. You would have to pass a comparison function which already is a problem on some targets. We could do better with static extensions that restrict to specific types (e.g. Vector<Int>), but these always have to be brought into context.

It would be nice if we could define multiple selective abstract functions with the same name. This would allow us to define sort(this:Vector<Int>) and sort(this:Vector<String>) directly on Vector itself.

I"ll have to think about this.

It would be nice if we could define multiple selective abstract functions with the same name. This would allow us to define sort(this:Vector) and sort(this:Vector) directly on Vector itself.

That is also what I was talking about WRT Map.iterator - we could probably implement selective iterator function that returns concrete class to make @SmerkyG happy 😉

@waneck: Shouldn"t this work on Java target?

abstract A<T>(Array<T>) {
    public inline function new(a:Array<T>) {
        this = a;
    }

    @:overload static inline public function sum(a:A<Int>) {
        trace("sum of ints");
    }

    @:overload static inline public function sum(a:A<String>) {
        trace("sum of strings");
    }
}

class Main {
    static function main() {
        var a = new A(["1", "2", "3"]);
        a.sum(); // A<String> should be A<Int>
    }
}

Type parameters evaluation are delayed IIRC. Why is that?
On Sep 23, 2014 7:42 AM, "Simon Krajewski" [email protected] wrote:

@waneck: Shouldn"t this work on Java target?

abstract A(Array) {
public inline function new(a:Array) {
this = a;
}

@:overload static inline public function sum(a:A<Int>) {
    trace("sum of ints");
}

@:overload static inline public function sum(a:A<String>) {
    trace("sum of strings");
}

}

class Main {
static function main() {
var a = new A(["1", "2", "3"]);
a.sum(); // A should be A
}
}

—
Reply to this email directly or view it on GitHub.

@waneck most likely because of constraints

I see. The problem is most probably there - IIRC a type parameter check failure bypasses the overload selection and just shows an error.

Hold on, this is at least partially my fault.

So, my example now works on Java and C#. I would like to suggest allowing this for abstracts on all targets with the requirement that the method be inline (and forcing the inline).

It would be great if this made it possible for Math.Max to properly deal with Ints instead of always forcing the return value to Float.

That would be an awesome addition, Simn!

I was trying to get it implemented, but there"s too much going on with pf_overload for me to get it right.