COMMUNITY

Comments welcome


(Peter Taylor Coates) #1

I’m a new but enthusiastic user, so I did a blog piece on Haxe. If anyone wants to comment or correct, please feel free and I’ll incorporate your input. https://hadoopoopadoop.com/2018/06/15/haxe/#more-7432


#2

It is nice to see a real problem that is solved by Haxe gracefully.
BTW, fortunately there is no ruby / objective-c code in your devices. :stuck_out_tongue:


(Jeff Ward) #3

Hello Peter! Welcome!

I’m somewhat fascinated by new users’ onboarding experiences – keep me in the loop as you continue your Haxe journey! You will (almost definitely) hit some snags, and I’d be happy to talk you through them, having recently journeyed this way myself.

Some comments on your post:

Really nice deductions and explanations. Everyone here will jump for joy that you recognized Haxe is a general purpose language and not a specific framework for a specific purpose. And also the part about the standard library having both cross-platform components, and platform-specific components.

As you said: strictly speaking, the Haxe compiler itself simply cross-compiles, but for some targets, a VM implementation is required (and provided). e.g. the hxcpp library (which contains a VM implementation) is required to target CPP. Same for the hl (aka hashlink) target. This VM includes a garbage collector and support for the high-level features of Haxe, e.g. function closures.

Since you mentioned IDL’s – my company is experimenting with describing some data types in graphql (which among other things includes a simply IDL). I’ve written a library for compiling graphql IDL to Haxe typedefs. That may be overkill for your purposes, but generally I agree – Haxe is a great language to define JSON-like structures.

And macros, as you say, generate code at compile-time. So, say you have a typedef which defines your valid JSON structure. With a macro, e.g. it could use this definition to auto-generate the Haxe code necessary to validate these structures at runtime. If that’s something you care to do.

You might also glance at the tink_json library. It’s a macro library for working with JSON in a type safe (and performant) way. But again, perhaps overkill for your application?

WRT inference… Yes, Haxe’s handling of type inference is fantastic. Basically, if you don’t type a variable, it’s a monomorph (of unknown type) until some later expression causes it to be inferred. Once inferred, it’s strictly typed. But this can trip you up occasionally. e.g. if you don’t type function arguments:

function do_something(a) {
  return Math.round(a);
}

And then you tuck a trace statement in there:

function do_something(a) {
  trace('Debug: a is: $a');
  return Math.round(a);
}

Suddenly there’s an error, because while a had been inferred as a Float, suddenly you inserted a line that inferred it as a String. For this reason, and for code readability, I (almost) always type function arguments. Just be aware of these things, and try to think like a compiler. :smile:

Anyway, lots of fun to be had with Haxe. Keep us informed on your progress! Cheers! :beers:


(Mark) #4

Welcome to Haxe! I found it a very nice and well-written article!

Some small comments:

  • Python target does have sys access.
  • You have links to haXe 2 books. haXe 2 is quite old. I mean so old that it was written like haXe; “we” just write “Haxe” nowadays.
  • We have more resources like the Haxe manual and the [Haxe code cookbook](https://code.haxe.org, which you could link if you want.

Btw, I once made this http://haxe.stroep.nl/how-to-say-haxe/ That is how you could pronounce Haxe :wink: :smiley: (I think it works only recent browsers)


(Peter Taylor Coates) #5

Thanks man. I tacked your comments on as and addendum to the posting rather than try to weave them in and risk confusing things. Same with Mark Knol below.


(Mark) #6

My name is mark, not mike :joy: