The code generated using haXe/PHP uses the PHP autoloading feature to dynamically load classes definitions when they are required. This method has many advantages but a drawback too; the thing is that the autoloading function (hidden in php.Boot) needs to scan the lib folder to look for type definitions. It is not really a big work since only the file names are read without the need to immediately open the files, nevertheless this work is made each time the page is accessed. To reduce the impact of this operation you can simply create a cachefolder at the same level of lib and give it the proper attributes for PHP being able to write files in there. On the next use of your script, a new file haxe_autload.php will be automatically generated and will contain all the info required by the autoloading function.

As you can guess, the impact of this feature is proportional to the number of classes included in your project.

Be warned that it is better to use the cache only on production sites because during development it is quite normal adding new classes and the cache will not include them unless thehaxe_autload.php file is manually deleted. If you need to upgrade your production code, remember to delete that file first!

edit: I’ve made a few informal tests compiling a project that generates 76 files but uses only a few of them to maximize the impact of the cache trick. The results are the following but remember that your mileage may vary greatly and you can also find out that you will not have any benefit from abilitating the cache feature.

Execution time:
198ms no cache
151ms cache activated (31% speed gain)

Starting from haXe 2.04 the PHP generator supports the -debug switch. The implementation is almost identical to the haXe/JS one where the function calls are stored in a stack. You can see it working when you have an uncaught exception or using the haxe.Stack methods as in the following example:

import haxe.Stack;
class Test {
  static function main() {
    var f = function() { ref(); };
    f();
  }

  static function ref() {
    throw "error";
  }
}

The output will be:

uncaught exception: error

Called from Test::ref
Called from Test::main@4
Called from Test::main

Note that @4 means that a local function is involved.
You can obtain the same output without generating an exception replacing throw "error" with:

trace(Stack.toString(Stack.callStack()));

Is it appropriate to remove the -debug switch when compiling for deployment since it adds extra code to your output.

If you are a haXe user you already know that PHP is already an official target of the haXe platform. The second version that includes PHP is 2.01 and it has reached a nice level of stability mainly thank to Nicolas who has adopted it for his personal website. He pointed out some annoying bugs that have been promptly fixed by me . But unfortunately for my personal life I realized that I still have a lot to work on to make haXe/PHP still better.

In CVS I have already made a radical change of direction to favor wrapping arrays into objects instead of using them directly. This has several implications; the main reason behind that is that in this way the compiler does not have to worry about passing by reference instead of by value. Other very important steps I will have to make in the future are optimizing as much as possible the generated code for performances, adding a debug version and creating as much tutorials as possible

The second release of haXe/PHP is available.

I would like to discuss here the development status of the project and maybe receive some feedback.

First of all, my todo list is almost empty and this is a good thing. The generator and the class libraries have made a big step forward from the first alpha. I consider the generator usable and I am actually using it for two small projects I am developing.

The last step I have to accomplish before passing to the beta status is to workaround some edge cases on strings and arrays. In the current implementation, strings (and arrays) are not encapsulated in objects and the compiler tries to resolve any occurrences in the following way:


"mystring".substr(0, 2);


is generated as:


php_Boot::substr("mystring", 0, 2);


The big advantage of this is that the code is fast but it leaves quite a big problem behind:


var d : Dynamic = "mystring";
d.substr(0, 2);


generates:


$d = "mystring";
$d->substr(0, 2);


In this case the compiler cannot correctly interpret the code and generates an invalid field access on a string value. The most obvious solution is to drop the native implementation and wrap strings (and arrays) into objects as Neko does … I’ve tried it and it has been painful … not the implementation of course but the performances have dropped to unusable. My full test suite that usually took a few milliseconds to be executed, passed to take a few (too much) seconds. The other solution, the one I am trying to figure out how to implement, is to wrap into objects only those occurrences that are not known for sure. So the above example would be transformed into:


$d = php_Boot::__box("mystring"); // now $d is an instance of php_HString
$d->substr(0, 2);


where __box is a function that makes a runtime typecheck on its argument and wraps it in a proper object if required. This function comes with the complementary __unbox that makes the reverse. This seems a good solution to me but I know it will not be easy to implement because the compiler will have to make a lot of look-ups to match the expected types with the passed types …. maybe Nicolas has some good advices on this

The other issue is the standard library. Many of the classes in the neko package have been implemented in php (Lib, Sys, SPOD and db related, File, Web …) and the idea is to cover the full package so that we can switch from and to the two platforms easily. To make it even easier, a neutral package exists that maps to the platform in use. So neutral.Web will automatically map to neko.Web or php.Web.

Some classes have not been ported yet because they extend the Input/Output classes. Those two classes are neko specific but in the haXe 2.0 they will become cross-platform using the new Bytes class. Because I am lazy I will wait for haXe 2.0 to implement them for PHP.