Writing externs: The problem of Multiple inheritance | Traits

I am currently playing around in writing PHP externs for the Processwire API (ProcessWire API Reference - ProcessWire API). But when for example starting with the Page class you encounter something like that:

In addition to the methods and properties above, Page also inherits the methods and properties of these classes:

  • WireData
  • Wire

Typical problem (especially when writing externs for js, btw) since Haxe Externs supports single inheritance only. Also no Traits, mixins or whatever.

But actually I found a way to solve that. tink_lang Partials to the rescue. Checkout this example:

@:tink interface Wire {
    function someWireFunction(): Void {};
}

@:tink interface WireData {
    var somewireData: String;
}


extern class Page implements Wire implements WireData {
    function doSomething();
}

class Test {
    static function main() {
		var instance = new Page();
        instance.doSomething();
        instance.someWireFunction();
     	trace(instance.somewireData);
    }
}`

I am surprised, but this actually works. Thank you very much @back2dos :wink:

Reason for this posts are 2:

First I wanted to share that tipp, because I was struggling quite a bit to get those kind of externs right.

But to be honest I am not sure if this is just clever… or “hacky”. I don’t even think tink_lang partials were intended to be used that way. So I would love to get some opinion. Is it “save” to do it that way?

Wonder if we maybe get some built in solution in Haxe4 for something like this.

1 Like

Traits would be awesome, but I’m not sure they mesh well with the way Haxe works. On the other hand, if some sort of trait system were devised, it would make Haxe more like Rust, which (imo) would be a good thing.

Well, not quite. They are called partial implementations and it’s not like you’re actually implementing anything. But if it works, great ^^

Absolutely.

So there was an attempt to do something about it for Haxe 4: Allow multiple inheritance on externs by ibilon · Pull Request #5797 · HaxeFoundation/haxe · GitHub

It got closed. I kind of see why. I guess the simplest way to deal with it would be to allow for extern classes to implement interfaces without having to declare the method signatures again (meaning the code could be allowed to compile without @:tink all the same).