Shoutout from the Apache PLC4X Team!

Hi all Hax-ers,

my name is Julian and I’m from the Apache PLC4X Team (plc4x.apache.org).
We are a pretty young Apache TLP and write drivers to allow “classical IT” to communicate with PLCs and Field Bus Devices on the Shopfloor.
As we want to support multiple drivers in multiple languages we are currently considering using some kind of code generation or Meta Programming.
Thus, we are learing about Haxe and trying to find out if this could be a good fit and who we could get things to work.

So this is just a hello to the community and a warning that questions will come :slight_smile:

Julian

16 Likes

Hey Julian! Welcome :slight_smile:

Your project sounds interesting! I’m curious to learn more about the use case - are you looking to produce device interface libraries for different languages?

Hey, :slight_smile:
Do you know which languages you want to target?

Hi haxiomic,
hi Michael,

thanks for the warm welcome!
Currently most of the code base is Java as we are mainly java guys.
But we are developing also Code in C++ and have bindings for C# and python in experimental stage.

So what we want to target overall should be around

  • C++
  • C# / .NET
  • Java
  • Python
    and hopefuly more, where there are use cases.
    Especially C should be interesting as it is used for embedded devices a lot.

So it should fit quite nicely with what Haxe already provides, I guess…

To go a bit more into detail to your question. Yes, indeed.
Currently we have several drivers (all through one standard interface) built in java.
So think of it as JDBC but for PLCs / Machines.
But now we want to extend this to different languages and for this, we have to use code-gen to keep it maintaineable.

Hi! Seems like a nice fit indeed :slight_smile:

A note on Haxe → C# .NET though: this target may be harder than the other ones atm because of some restrictions:

  • static extension not working with overloads, so when the one picked by haxe compiler isn’t the one you need, you have to call the static method manually or do some abstract magic; nothing really bad but can get annoying when porting C# code.

  • sometimes static functions work with type parameters that do not appear in either the arguments or the return type. In haxe, you cannot pass type parameters in your function call (as in var a = myMethod<Int>();) but it’s usually fine as long as the compiler can infer it (static function myMethod<T>():T with var a:Int = myMethod() will work just fine for example). When it just can’t (static function myMethod<T>():Void), you can’t pass T. This one is trickier to work around, but there’s always a way.

I use Haxe → C# .NET (core) in production, but other haxe targets are really easier to work with. So if you start with some tests with Haxe → C# .NET and find it annoying/hard do not assume it will be the same with other targets :wink:

On a positive note, C# dlls can be parsed by Haxe so you have “free externs” o/ [1]

Hey @kLabz, thanks for the nice words.
I think this is something we can live with as we are totally aware of the fact that we do Meta Programming, so we can stick to rules as those.
But, I think, as soon as we really commit to this approach there will be a lot of questions to all of you guys : )