←back to thread

PHP 8.5

(stitcher.io)
214 points brentroose | 2 comments | | HN request time: 0s | source
Show context
darkamaul ◴[] No.45990664[source]
PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.

I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.

replies(12): >>45990804 #>>45990834 #>>45990835 #>>45990949 #>>45991400 #>>45992500 #>>45992620 #>>45992776 #>>45993443 #>>45993687 #>>45995052 #>>45995108 #
phplovesong ◴[] No.45990834[source]
PHP has no generics? I read somewhere that is was "too hard" to get right in PHP land, mostly because of how primitive the typesystem is.
replies(3): >>45991417 #>>45991444 #>>45992643 #
deaddodo ◴[] No.45991444[source]
It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).

Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.

replies(1): >>45991948 #
phplovesong ◴[] No.45991948[source]
> And would be a massive headache to implement

Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.

> Adding generics to PHP would make CS fundamentalists somewhat happy

PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.

For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.

replies(4): >>45992880 #>>45992994 #>>45993750 #>>45994285 #
duckerude ◴[] No.45992994[source]
Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker.

PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)

The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.

replies(1): >>45993947 #
1. phplovesong ◴[] No.45993947[source]
Precisely. PHP has tools for this too, but lack the syntax. Right now you need to to all typings in comments, and thats just as bad as jsdoc was in 2005.

This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.

But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".

replies(1): >>45994268 #
2. duckerude ◴[] No.45994268[source]
The current amount of typechecking might be a net efficiency improvement AFAIK. It provides a hard runtime guarantee that variables are certain types while Python has to check whether something is supported at the last possible moment. But I don't know how much use the optimizer makes of that.