add prefix in @:phpConstants

[mockey]

No description provided.

[mockey]

This adds the possibility to add a prefix in @:phpConstants. So now you can write:

@:native("\\")
@:phpConstants("SOAP_SSL_METHOD_")
@:enum extern abstract SoapSslMethod(Int) {
  var TLS;
  var SSLv2;
  var SSLv3;
  var SSLv23;
}

And you get: \SOAP_SSL_METHOD_TLS in PHP. Saves a few keystrokes.

[Simn]

What's that @:native("\\")?

[mockey]

Global namespace. You can also use @:native(""), but that's not really global in current PHP.

[mockey]

Hm, I just saw, that @:native("\\") is causing problems with the compilation server. When there are multiple classes/abstracts/enums with @:native("\\"), it says:
"Type name \ is redefined from module xxx"
This only happens with the compilation server. Could this be avoided somehow?

[mockey]

Ah, using @:native("") instead gets rid of the error for now :-)

[mockey]

Hm, strange. I added another comment 2 days ago, don't know where that went.
Anyway, @:native("") doesn't fix the problem. The error is: "Type name is redefined from module xxx" then.

As I wrote in #4876:
I simply added:
if s_type_path t.mt_path <> "" && s_type_path t.mt_path <> "\\" then
before this line:
https://github.com/HaxeFoundation/haxe/blob/development/src/typing/typeload.ml#L2838
to exclude the global php namespaces from that error.
That makes the error go away. But I'm not sure if that's the best place for such a fix, because typeload.ml is used in all targets. If it's OK I can add it to the PR.

It would be nice to have this error fixed, because being able to define externs in the global namespace is a real improvement for the php target, I think.

[Simn]

Hmm, I'm not sure if that part of the typer should come across type paths that have been influenced by @:native. This might be a more general problem with the compilation server because the module type path is used as a hashtable key.

I wonder if there's a missing check for @:realPath somewhere in the compilation server code, but it's not easy for me to tell. Assigning to @ncannasse for further advice.

[ncannasse]

The compilation server should correctly restore the original class name since it does save/restore cl_path

[ncannasse]

But I think that's quite a bad idea to have clashing names to classes, we definitely don't want to support that. Why not using @:native("\SOAP_SSL_METHOD_") ?

[mockey]

Hmm, I'm not sure if that part of the typer should come across type paths that have been influenced by @:native. This might be a more general problem with the compilation server because the module type path is used as a hashtable key.

What is the module type path? SoapSslMethod or the native one? I get an error about the native one \ from the code above and only from the compilation server.

I wonder if there's a missing check for @:realPath somewhere in the compilation server code

Maybe. As I said: no errors in normal compilation. I wouldn't have made that PR otherwise.

The compilation server should correctly restore the original class name since it does save/restore cl_path

Again: What is the original class name? SoapSslMethod or the native one?

But I think that's quite a bad idea to have clashing names to classes, we definitely don't want to support that.

But these are only the extern native names or paths...

Why not using @:native("\SOAP_SSL_METHOD_") ?

Because that would generate: \SOAP_SSL_METHOD_::TLS (class-name::static-field-constant). I made a PR that deals with @:native("") and @:native("\\") especially, so that no :: is generated there.

The thing is: PHP has lots of functions, constants and what not in the global namespace. It would be nice to be able to use them directly from Haxe with extern classes and abstracts (just like you can in other targets). And basically it works quite well. There's only this problem with the compilation server. Could you have a look at it mabe?

[ncannasse]

@mockey I think it's a bad idea in general to rely on same class names not clashing, this might break anytime in future haxe updates and we don't have to have to support this exception. Try to find another way to get the same result without using @:native

[mockey]

@ncannasse

I think it's a bad idea in general to rely on same class names not clashing

I'm not sure if I would consider "" or "" as real class names.

Try to find another way to get the same result without using @:native

What about a PHP-specific solution then with an own metadata like @:phpGlobal?

[ncannasse]

@mockey using @:native will change the internal class name in haxe system

A PHP-specific solution is ok.