Questions and Problems with the haxe-php target

[flammehawk (Sebastian Mai)]

Greetings,

currently I’m a PHP + JS Fullstack Developer and I’m at the moment evaluating if I maybe should use Haxe for some of my private projects.

The language in itself seems nice, so that is a big Plus for it.

But the big But that speaks against it is are some things:

1. First of all the PHP code that gets generated.

   • I would Imagine that the Main Class that I define gets turned into the Entrypoint of the Application. In the case of PHP I would imagine it gets turned into the Index.php, which it does not instead I get a Generated index.php that does some haxe intern Bootstrapping before starting my Main class.
     • Question: Is their a way to Disable this behavior? So that I can generate my own Index.php and handle the bootstraping myself? This would make it easier to use existing PHP frameworks together with haxe
   • The haxe lib files that get generated Why are they situated in the same Namespace as my Application if I use the -D php-prefix=App compiler flag?
     • These Haxe-libs should not be in this Namespace they are not part of my Application.
     • They should have their own Namespace like namespace \Haxe\Php;
     • And they should not be located in my Application folder, it should be more like this See the Screenshot
     • Someone already made the effort to build a composer Package for it https://github.com/cedx/haxe.php
       • Maybe we could have a compiler Flag that makes use of that package instead while building the Application like -D php-composer=true something Like that flag could be used for NPM as well.

2. Integration of Composer packages

   • Currently it just seems like a Pain to use Composer packages together with Haxe.
   • What I understand is that I would need to write an external Class for nearly every Class of a Package that I want to use in my application.
   • I know their is a already a project on github that want’s to deal with that problem: https://github.com/RealyUniqueName/peg
   • But would it be an Option to check if a Composer Package already includes External definitions for its classes? Like in JS where a npm package can provide it’s own Type definitions.

3. Project Structuring

   • Currently we define our targets per CLI arguments or per .hxml file
   • But that makes it hard in my eyes to define a Project with multiple Components Like One part is the Backend and One part is the Frontend. could we per chance maybe define this instead of a custom file format with either an .xml file or even Json/yaml file with a corresponding Schema definition so that It gets more readable and maybe even gives better integration with IDE plugins since they don’t need to read a custom format and write their own parser but could use existing ones.

Screenshot

I will still give Haxe a try and see how far I get with it.

[ablum (Alexander Blum)]

regarding generating index.php there are two options: either use -D php-front=notIndex.php which will put Haxe’s entrypoint into notIndex.php which would still be accessible and launch your Haxe main() function, so probably not the best option. or you can just replace -main mycompany.myproject.MainClass with mycompany.myproject.MainClass in your .hxml or command line options and Haxe will generate lib folder but not overwrite your index.php.

if you use -D php-prefix=App you are telling Haxe to put all generated classes below namespace “App”. if you want to have \Haxe\Php, you will have to use -D php-prefix=Haxe/Php instead.

I don’t use composer packages, so I can’t say anything about that. I usually try to use pure Haxe stuff, so I wrote my own libraries.
as far as externs go you only need to write externs for classes that you use and you can limit your externs to what you actually want to use. that might reduce the number of externs you need, but that depends on your usecase.

Haxe’s VSCode plugin comes with support for .hxml file format.
I usually have multiple different .hxml files, some for building, some for display / completion support and some for testing.
to build the full project with multiple targets I often add a build/Build.hx that executes compilation calls via Sys.command.
you might also be able to use one big .hxml file with --each / --next sections.

[RealyUniqueName (Aleksandr Kuzmenko)]

Question: Is their a way to Disable this behavior? So that I can generate my own Index.php and handle the bootstraping myself? This would make it easier to use existing PHP frameworks together with haxe

You can specify your “entry class” directly instead of specifying --main compiler argument:

# instead of
--main Main
# do this:
Main

In this case “index.php” won’t be generated and you’ll have to create an auto-loader by yourself.

However it should be sufficient to just include haxe-generated “index.php” somewhere in your own “index.php”.

You can also use composer’s capabilities to load classes, an example of which you can see in this video: https://www.youtube.com/watch?v=OkyMPkUEZxo

The haxe lib files that get generated Why are they situated in the same Namespace as my Application if I use the -D php-prefix=App compiler flag?

Due to the nature of Haxe libraries there’s no reliable way to distinguish if my.pack package comes from your project or from a 3rd-party library at the generation step of compilation.

As a workaround you can compile a library separately from your project and then refer to library’s types through externs.

I agree this is not convenient and can be improved. Feel free to propose any ideas for discussion.

Someone already made the effort to build a composer Package for it https://github.com/cedx/haxe.php
Maybe we could have a compiler Flag that makes use of that package instead while building the Application like -D php-composer=true something Like that flag could be used for NPM as well.

You can use a compilation argument --macro exclude("pack") to prevent any types in pack package from generating php code.

would it be an Option to check if a Composer Package already includes External definitions for its classes?

If extern definitions are already provided somewhere, all you need to do is to add a classpath of those externs. For example if you have a composer package “my-lib”, which contains extern definitions in a subdirectory “haxe-externs”, you just need to add this to hxml or compilation arguments: --class-path vendor/my-lib/haxe-externs/

Currently we define our targets per CLI arguments or per .hxml file
But that makes it hard in my eyes to define a Project with multiple Components Like One part is the Backend and One part is the Frontend. could we per chance maybe define this instead of a custom file format with either an .xml file or even Json/yaml file with a corresponding Schema definition so that It gets more readable and maybe even gives better integration with IDE plugins since they don’t need to read a custom format and write their own parser but could use existing ones.

We have discussions about a project file format from time to time, but have not come to consensus yet. Some Haxe frameworks solve this issue with their own project formats. There’s also a separate package manager, which you may find interesting: Lix

[flammehawk (Sebastian Mai)]

First of all thank you both for answering.

@RealyUniqueName

# instead of
--main Main
# do this:
Main

That already helps a lot

@RealyUniqueName

You can use a compilation argument --macro exclude("pack") to prevent any types in pack package from generating php code.

This is as well help full, just leads me to an issue with the Haxe Std it seems like their is no Root Package for it which results in not being able to exclude it in full using --macro exclude("pack") But that is something I should probably report inside a gh issue

And Lix realy looks interesting I will probably give it a try.