Type check and cast

21

Juraj :rofl: :rofl: :rofl:

When I say that it’s too much work for nothing, this is because at the begining I was looking for just a Haxe keyword or built in feature that allows to BYPASS HAXE TYPE CHECK SYSTEM AT COMPILE TIME (without any run-time overhead).

You’re as obstinated and chatty as I am ! :rofl:

I’ll explain how my brain worked and propulsed me here to “talk” with my coding friends :slight_smile: :

  • At the begining, I found by myself that unsafe cast does almost what I want. I compiles well and it’s ok.
  • Then I came here to ask the difference between unsafe cast and the type check (e:T), because for me these 2 options are very close and I was sure that unsafe cast doesn’t bring any run-time overhead.
  • BUT Kevin told that in fact sometimes even unsafe cast can add some run-time overhead on some plateforms…
  • So, my brain focused again on the type check (e:T) that doesn’t bring any run-time overhead BUT Jens said that type check is not really doing what I thought
  • So again, I was confused with (e:T) and in fact I still don’t really understand the utility of this feature (here you can help me if you want to answer, with maybe some simple examples :slight_smile: )
  • Then Kevin bring another solution (and I thank him again for this try) using macros to ensure that all is strictly typed and does what I want. This is very cool but at the end I just realized that I don’t really want to use macros to ensure that on compile-time all types are ok because it’s my own code, I don’t share it without any other coders, so I KNOW WHAT I DO and I just wanted again to find a way to BYPASS HAXE TYPE CHECK SYSTEM AT COMPILE TIME

That’s all ! :slight_smile:

Then, reading you’re last paragraph, static function foo<T:Class<Dynamic> & { function bar():Map<String, String>; }>(cl:T) is antoher interesting and elegant solution and I haven’t thought about that. I think that if you had written that at the begining, I would be satisfied and even maybe get an orgasm :rofl: (but once again, I think my bad english create sometimes confusion about what I’m really looking for…)

You’re last solution also show’s me that in fact, I have a misunderstanding of how Haxe manages Types globally, because I must admit that I’m not really comfortable with generics and all related with Type casting as seen here with the Type Checking (e:T). All that occurs on compile-time.

If there is somewhere a good tuto to explain step by step the utility of generics agains Dynamic for example and at the end as I asked, the real utility of (e:T) I would be happy.

And what about my research of not having run-time overhead is not because I care to have the fastest and smallest generated code, it’s once again related just to this topic to just find a way BYPASS HAXE TYPE CHECK SYSTEM AT COMPILE TIME , once again related to these 2 options between unsafe cast and type check.

Thanks all my friends coders, have a nice day !

22

This is nuts. Use a freaking unsafe cast. That’s exactly what you’re looking for. I don’t know how else to explain that to you or if I have to write it out in Bart Simpson style.

Whether or not there is a runtime overhead has nothing to do with Haxe at all. Static targets each have their own type system that simply cannot be bypassed without runtime overhead, because that’s just how they work. Consider the following Java code:

class Main {  
  public static void main(String args[]) { 
    foo(Main.class);
  }

  public static String bar() {
    return "bar";
  }
  public static <T extends Mains> void foo(Class<T> c) {
    c.bar();
  }
}

There is no way you can make that compile without adding overhead (e.g. via reflection). No amount of YELLING AT ME can possibly change that.

So please just accept the fact that an unsafe cast is what you want and if you truly seek to minimize runtime overhead, then you should not break out of Haxe’s type system in the first place, because it’s quite carefully designed to map onto all of its static targets with minimal overhead.

3 Likes
23

All the answers have been given, and this is starting to run in circle, so I’ll close this topic.

2 Likes