Class with type parameters <K,V> with a Map<K,V> member?

[Benjamin Sinkula]

Given the following code:

class Dictionary<TKey, TValue>
{
    private var _map:Map<TKey, TValue>;

    public function new(?map:Map<TKey, TValue>)
    {
        if (map != null)
            _map = map;
        else
            _map = new Map<TKey, TValue>();
    }
}

But trying to compile this, I get the following error:

HaxeWrapper.hx:73: src/haxesharp/collections/Dictionary.hx:13: characters 19-42 : Abstract Map has no @:to function that accepts IMap<haxesharp.collections.Dictionary.TKey, haxesharp.collections.Dictionary.TValue>

The issue lies with trying to construct the new Map<TKey,TValue>(), is there any way to accomplish this?

Can anyone shed some light on this? I thought, based on the class's type parameters, and everything would just work, but I was clearly wrong! There must be something about type parameters and/or abstracts that I am missing?

Any help is appreciated, thank you.

[Chii Chan]

you don't need to add generic parameters to the constructor.

change `new Map<TKey, TValue>();` to `new Map();`.

[Benjamin Sinkula]

No luck, unfortunately.  The updated code produces the same error as before.

[Simon Krajewski]

Short answer: Constraint your TKey type parameter to "object": `class Dictionary<TKey:{}, TValue>`

Long answer: Haxe picks a Map implementation at compile-time, and cannot do that when you hide the key type behind type parameters. The map implementations for various key types (string, int, object) differ greatly on some targets. Since Haxe does not specialize classes per type parameter combination by default, the nature of your TKey type is unknown to the compiler, and it cannot decide which map implementation to pick. By constraining it to {}, it can tell that what you want as key types are objects, so it can pick haxe.ds.ObjectMap accordingly.

And yes, we should change the error message to something more reasonable.

Simon

[Benjamin Sinkula]

Thanks for the reply.

The one issue with making TKey constrained on {} is that it appears to reject Int (and possibly others) as a TKey value then: Int should be { }

Is there a simple workaround for that error that I'm missing?

[Jeff Ward]

Indeed, {} is any object type, but not Int, Bool, Float (maybe some others?).

Seems odd - you'd imagine all the type parameters should be known at compile time?

Random thought - given the sample code, it looks like your Dictionary class may just be a wrapper (adding some logic?) around (any) map? If you can describe your additional logic as a static extension, then your logic can apply to any Map: https://try.haxe.org/#EC3d0

Of course, if/once your Dictionary class needs member variables, static extension isn't suitable.

Good luck!

-Jeff