4 ms·

In theory, it sounds pretty interesting. PHP's ethos is quite different though - e.g. PHP's "arrays for everything" vs Java's "specific types for every case". A

In theory, it sounds pretty interesting. PHP's ethos is quite different though - e.g. PHP's "arrays for everything" vs Java's "specific types for every case". Also, the absence of generics in PHP is a huge difference.

mschuster91 3y ago
At least the PHP-in-JVM side shouldn't be that complex to do then... a LinkedList<Object> should be enough to match PHP arrays functionally. The largest challenge in a PHP-in-JVM project probably would be re-implementing its large stdlib as a wrapper around native Java.
- actionfromafar 3y ago
  Or, don't: as in compile PHP library to JVM. Something like https://github.com/mridoni/llxvm https://github.com/mridoni/llxvm
DarkNova6 3y ago
> PHP's "arrays for everything" I think that's more a framework/library philosophy than anything else. When I dabbled with PHP + symfony, I worked with some of the most clean APIs I've seen to this date.
- berkes 3y ago
  PHP core has very few datatypes. And many are really just Arrays. Not just "under the hood" but through public interfaces. The best example to show this is that you can `foreach()` over an object. It wasn't a deliberate feature but rather an artifact of how objects are "syntactic sugar over Arrays" and how Arrays are really just hashtables. And it becomes problematic with the many exceptions that all the functions operating on Arrays have. Almost all important functions' documentation (edit: on arrays) goes something like "if the array key is a string, it will act like X, if it is a number it will act like Y". With some going like "if one of the keys is a string it will X, otherwise it will Y". And Y and X being rather different in return values, errors and such. I can understand that PHP has a really strong preference for strings - HTTP is only and all strings after all - but the mess around arrays is real, dangerous, and has bitten me, my companies and many of my clients many times over. For decades.

mschuster91 3y ago

At least the PHP-in-JVM side shouldn't be that complex to do then... a LinkedList<Object> should be enough to match PHP arrays functionally. The largest challenge in a PHP-in-JVM project probably would be re-implementing its large stdlib as a wrapper around native Java.

actionfromafar 3y ago
Or, don't: as in compile PHP library to JVM. Something like https://github.com/mridoni/llxvm https://github.com/mridoni/llxvm

DarkNova6 3y ago

> PHP's "arrays for everything" I think that's more a framework/library philosophy than anything else. When I dabbled with PHP + symfony, I worked with some of the most clean APIs I've seen to this date.

berkes 3y ago
PHP core has very few datatypes. And many are really just Arrays. Not just "under the hood" but through public interfaces. The best example to show this is that you can `foreach()` over an object. It wasn't a deliberate feature but rather an artifact of how objects are "syntactic sugar over Arrays" and how Arrays are really just hashtables. And it becomes problematic with the many exceptions that all the functions operating on Arrays have. Almost all important functions' documentation (edit: on arrays) goes something like "if the array key is a string, it will act like X, if it is a number it will act like Y". With some going like "if one of the keys is a string it will X, otherwise it will Y". And Y and X being rather different in return values, errors and such. I can understand that PHP has a really strong preference for strings - HTTP is only and all strings after all - but the mess around arrays is real, dangerous, and has bitten me, my companies and many of my clients many times over. For decades.