@:native("") externs, for global (unqualified) functions in target language

[jcward]

Apologies if this issue already exists, I searched for @:native and global

When specifying externs, it seems logical to use @:native("") to indicate that the functions defined by the external library are global -- that is, they need no namespace or class qualification. I've tried to use @:native('') before, and @nadako recently mentioned it here.

For example, if I had a JS library that globally defined the print function:

@:native("") extern class MyLibrary
{
  public static function print(msg:String):Void
}

But when using this extern, the resulting js output still has the . prefix:

   .print('foo');

Or, in PHP output, it has a :: qualifier

  ::print('foo')

So the requested feature is (pending debate below):

1. if the native metadata is empty string, don't prepend a qualification separator such as . or ::
2. ideally, it should be possible to rename local vars to not collide with the native global

There are some ugly workarounds that work in specific cases -- e.g. @:native('REMOVEMEPOSTPROCESSOR') and for js (browser only not nodejs), @:native('window') sometimes works -- but it'd be ideal if the compiler could generate global function calls in the target language.

[jcward]

Ah, I am now finding some related issues: #6411 #4876 #2925

Ok, I think @ncannasse's comment here explains why this hasn't been done to date:

There might be a local variable named (the same as the expected global).

Hmm, I suppose that's the danger of global functions. But arguably, if the target language allows them, then externs should be able to support them.

There may be another workaround which involves scoping the global functions... Lemmi think...

[ibilon]

The c++ target has a different behavior,
it expects extern static functions to have a @:native which will be the entire syntax, it doesn't add the extern class name at all.

[nadako]

The safest way currently is to rely on environment-provided "global" name, such as window on browsers, global on nodejs (as i do in hxnodejs), _G on lua, etc.

However, maybe we could consider @:native names when renaming local vars, similar to what's done for #6409... The main issue here, I guess is that different targets handle @:native differently, and often have additional specific metadata for this, so we might want to clean this up (or at least gather a list of these metas) first.

[RafaelOliveira]

Today there are js environments (like the fantasy console TIC80) that has some global functions available to the users. If the user create a local variable with the same name of a global function, this is a problem of the user, because the program will crash anyway.

[nadako]

If the user create a local variable with the same name of a global function, this is a problem of the user

this is true for for javascript, but not for haxe. in haxe there are no global functions and there's always ways to access class statics, so this should work in Haxe unaffected by local variables. as i said, ideally the compiler should take care of this by renaming local variables to prevent name clashes.

because the program will crash anyway

why? in js it's supposed to just overshadow the global function so it won't be available in this scope.

[jcward]

Interesting, perhaps unrelated, but there is already some use of @:native("") in the Java standard library. Introduced in 0dc1500 / e6ea0c6 as a workaround / solution for #4113

[RafaelOliveira]

There are other environments where we don't know if there is a global name, like the TIC80 that I mentioned. It can be V8, or it can be other js engines, most of the time this info is not public.

[jcward]

Regarding the local var name conflict argument, this is already possible, e.g. Math.isNaN is defined in the standard library:

	@:pure static inline function isNaN( f : Float ) : Bool {
		return (untyped __js__("isNaN"))(f);
	}

This conflicts with a local var named isNaN: https://try.haxe.org/#208B7

[nadako]

This conflicts with a local var named isNaN

A good catch actually, this should be handled in the js generator along with other identifiers. It actually is handled for local variables, but not for argument names it seems, that's another bug...

[nadako]

aand it's gone :)

[nadako]

@:native("") extern classes should work now (with local vars renamed accordingly), i only implemented that for js for now. but it might make sense to support that on lua and python as well.

[NQNStudios]

I'm running into this problem on Python right now. I want to be able to pass global python functions around as variables in my Haxe code, and the code is getting generated with the . in front of the global function name.

[NQNStudios]

Thank you for the swift response!

[LordMZTE]

I'm still getting this on the lua target when trying to use a native field. I need haxe to generate some lua code like this

Foo = "bar"

but I've not gotten that to work. I tried this

@:native("") extern class Foo {
    @:native("Foo") static var foo:String;
}

function main() {
    Foo.foo = "bar";
}

but that generates .Foo = "bar" in lua, so invalid syntax.

EDIT: I'm using haxe 4.2.3. I can try master if there might be a fix.