Abstract Map has no @:to function that accepts IMap<remove_all.K, remove_all.V>

[dlots]

public static function remove_all<K,V>(map:Map<K,V>):Void {

On the above declaration. This compiled previously.

[Jason O'Neil]

I've run into this also.

Is there a reason that Map does not define `@:from` and `@:to` casts for `IMap<K,V>`?  It would make it easier when you use a custom map implementation, something other than the ones in the standard library.

Jason

On Wed, Nov 6, 2013 at 8:53 AM, dlots <image...@gmail.com> wrote:

public static function remove_all<K,V>(map:Map<K,V>):Void {

On the above declaration. This compiled previously.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[dlots]

I am using commit btw until this is fixed:

fa24ce0a6016ca26c2aa5cb706eea1e28d814653

[Juraj Kirchheim]

I believe the reason for that is the multi-type nature of Map.

What this allows is for Map<String, T> to always become
haxe.ds.StringMap and not my.custom.StringMap. This in turn means that
most of the time the abstraction comes at no overhead, because it is
substituted for the concrete class and thus further optimization like
inlining will work.

If you want to write code against something as generic as IMap, you
will have to write it against IMap explicitly.
Or you can use @:generic, that should also work. It's trading away the
overhead of IMap against the overhead of implementation for different
value types (even though not necessary).

Regards,
Juraj