2 ms·

The stdlib is part of the language, and while theoretically someone could take PHP and pair it with a new standard library, they could also take the PHP VM and

by dvdkon 4y ago

The stdlib is part of the language, and while theoretically someone could take PHP and pair it with a new standard library, they could also take the PHP VM and pair it with a new syntax and parser with not much more effort. Just as its standard library is one of Python's biggest strengths and almost lacking one is one of JavaScript's biggest faults. Even if a community project is created to replace PHP's stdlib and offer a better alternative, unless everyone adopts it, it will always be just a niche alternative. PHP needs to actually have a good standard library in its default distribution. Maybe looking to large frameworks like Symfony to develop one isn't a bad idea, but they've largely left the stdlib alone, so just waiting for them to start developing a complete replacement isn't going to work. (For all its faults, JS' parseInt function is perfectly serviceable, but that's beside the point.)

tored 4y ago
My proposal would be to let the community build a stdlib and after it is battle tested merge it with core PHP. It has been proposed before to have PHP source shipped with PHP (and also the possibility mix C and PHP) and think that would be the best option. One option could be to have slower evolved stdlib in core and a faster community version with composer. Reason why I’m proposing to develop it outside of core is because a rfc based process is not necessarily the best approach to design a good & well functioning api (and empirically that is true). It is better to deliver a complete stdlib (or major sub parts) as one or multiple rfc. And by doing like this you allocate resources better, the few with knowledge about PHP internals can keep focusing on that while the community, a much larger group, can design a stdlib. And PHP has done a lot of great work on making user land and stdlib on equal footing, so now you can implement strpos(…) to exactly match the stdlib version thanks to union types, similar argument parsing and using same type rules (type errors) between the too. Only major thing I know of that differs when exposing an api, that is either from a PHP C extension or PHP code, is operator overloading. A rfc proposal to add it was unfortunate declined, but I’m hopeful that on day it will be added in some form because of this reason, it ought to be possible to express the same intent regardless if it is from C or PHP. With user land operator overloading we can implement object based primitives with methods instead of the current function based approach. And it could be possible to extend it. Other nice things you could do is to implement safe and unsafe string handling to avoid injections. With operator overloading the community can evolve the language without the need to evolve PHP itself.
- deleted 4y ago
  [deleted]

by dvdkon 4y ago

tored 4y ago

My proposal would be to let the community build a stdlib and after it is battle tested merge it with core PHP. It has been proposed before to have PHP source shipped with PHP (and also the possibility mix C and PHP) and think that would be the best option. One option could be to have slower evolved stdlib in core and a faster community version with composer. Reason why I’m proposing to develop it outside of core is because a rfc based process is not necessarily the best approach to design a good & well functioning api (and empirically that is true). It is better to deliver a complete stdlib (or major sub parts) as one or multiple rfc. And by doing like this you allocate resources better, the few with knowledge about PHP internals can keep focusing on that while the community, a much larger group, can design a stdlib. And PHP has done a lot of great work on making user land and stdlib on equal footing, so now you can implement strpos(…) to exactly match the stdlib version thanks to union types, similar argument parsing and using same type rules (type errors) between the too. Only major thing I know of that differs when exposing an api, that is either from a PHP C extension or PHP code, is operator overloading. A rfc proposal to add it was unfortunate declined, but I’m hopeful that on day it will be added in some form because of this reason, it ought to be possible to express the same intent regardless if it is from C or PHP. With user land operator overloading we can implement object based primitives with methods instead of the current function based approach. And it could be possible to extend it. Other nice things you could do is to implement safe and unsafe string handling to avoid injections. With operator overloading the community can evolve the language without the need to evolve PHP itself.

deleted 4y ago
[deleted]