What's the status of Haxe "@:selfCall?"

I need to do two things in order to use the “Leaflet” library (with Greg Dove’s code):

(a) I need to be able to say, “Implements IProjection,” without the following snippet of JS code being generated:

OurProjection.__interfaces__ = [leaflet.geo.projection.IProjection];

… not only because there’s no “Leaflet” variable (haven’t figured out how to get rid of that one yet), but also because the Leaflet.js library never actually defines “an interface” anywhere in its source-code.

(b) Most importantly, I need to be able to “extend” an object which does not have a “new()” method in the JavaScript. I read about a @:selfCall pragma, and indeed I find that my haxe (3.1.3) seems to accept it. (It doesn’t throw a compile-error …) But the apparently-mandatory super() call still tries to call a non-existent new(). (It even inserts a parameter to that phantom call.)

What can I do to call this library correctly?

Okay, I see that @:selfCall is only in the release-candidate version of Haxe. I downloaded that, and now it omits the call to the non-existent new().

But I am still having a problem where it attempts to set __interfaces__ to a non-existent JavaScript thing.

This is declared to be an extern interface. And it’s exactly that: an abstract interface (referred-to in Leaflet documentation), but non-existent in the JavaScript library itself.

This last appears to me to be a bug/enhancement needed in haxe … or maybe it’s already there? A reference to an “interface” in an external JS library might or might not refer to something that actually exists.

I am also noticing that, if I want to extend CRS to get the goodness of the existing JS object, I am forced to call super(), and this seems to cause a superclass-call to occur even though, in the extern definition, i have added @:selfCall.