Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you need (and don't need) to know about PHP's type system

thephp.website

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Everything you need (and don't need) to know about PHP's type system

#61

Post by 87zuhjkas »

kyriakos wrote: post #45
bsdubernerd wrote: post #44

Earlier quoted context omitted.

I always used and use PHP because it gets the s$$$ done. But truth be told, the hate is deserved. It never was a particularly efficient language, which might not matter that much, but it was riddled with gotchas, warts and horrible solutions to many technical and social problems. Today PHP is faster than many alternatives, many of its warts got fixed, but I cannot brush off the fact that it's still based on a poorly-…

I agree with both statements, it gets shit done but has its rough edges. Its improving though and I doubt there's a perfect programming language out there. At the end of the day what matters are results and how quickly you went from idea to production and PHP is one of the good ones for that matter.

I think "rough edges" is an understatement. It has serious design flaws and inconsistencies which are probably never going to be fixed due to backwards compatibility. It's like C++ now, tons of language features are added over the years but non of them is able to repair the language, similar to a game of Jenga, the tower will collapse eventually.

Re: Everything you need (and don't need) to know about PHP's type system

#62

Post by nawarian »

chx wrote: post #11

Minor nits: 1. "they all inherit from stdClass" -- this is simply not true 2. callables should've mentioned anonymous functions 3. a special typed value can't be casted to anything. -- this is not true, NULLs can be casted to anything (it becomes 0, "", array() ) and even resources can be casted to anything with dubious utility value. 4. casting should mention the intval() , strval() , doubleval() functions 5. php do…

I'll definitely edit the post adding the relevant bits you mentioned.

Two special notes:

About 1. stdClass, you're right and I don't know why I just took it for granted without even testing. My Bad.

About 3. casting special types, you're right again. I didn't phrase it properly. Casting null to other types won't yield errors and casting resources too. Their values are normally nothing we should rely on, but doesn't mean one "can't" perform such casts.

Thanks a lot for your comments, they are incredibly helpful! Cheers!

Re: Everything you need (and don't need) to know about PHP's type system

#63

Post by nawarian »

epse wrote: post #56
untog wrote: post #49

Earlier quoted context omitted.

Match looks exactly how Rust’s match works and it’s one of my favourite parts of the language. Happy to see it elsewhere too.

It doesn't really pattern match like rust, but it's still very useful

Not yet: https://wiki.php.net/rfc/match_expression_v2#future_scope

Re: Everything you need (and don't need) to know about PHP's type system

#64

Post by nawarian »

asddubs wrote: post #52
simonhamp wrote: post #23

Earlier quoted context omitted.

A lot of what Hack introduced to the PHP community has become available in suitably forward-thinking ways to allow for a sensible amount of backwards compatibility and are opt-in. For example, you can set strict typing on a per-file basis. `declare(strict_types=1);` I believe that the performance difference between the two is negligible now too. So it really just comes down to personal preference/platform legacy. But…

the only thing that sucks about strict typing is that there's no way to toggle it globally. so if you want to transition a codebase that's simultaneously actively being developed in other ways, you have to mess around with scripts that append it to the start of all php files/remove it again

Nothing that tools like Rector can't help you with.

I believe this extra step is incredibly important, given most of your dependencies you won't control and forcing strict types to them is not very clever IMO.

Re: Everything you need (and don't need) to know about PHP's type system

#65

Post by nawarian »

choma wrote: post #46

Completely unrelated but, if the site owners read this: pleas, make the CSS ::selection a different color from the background, please!!

Thanks for pointing this out. It annoyed me a lot as well. The whole "dark mode" css was a "better than nothing" thing, and now I'm collecting the "must fix" things. This is definitely on the list!

That said: the website is open source, feel free to submit a PR if you find time before I do :D

Re: Everything you need (and don't need) to know about PHP's type system

#66

Post by nawarian »

wolco wrote: post #51
fennecfoxen wrote: post #40

Earlier quoted context omitted.

Eh. If MyPy complains that I'm passing an `Optional[Entity]` into a method where only an `Entity` can go, it's just helped me avoid a runtime error when I try to get `entity.name`. Not sure what the exact PHP equivalent is, but there's all sorts of bugs you can easily introduce if you're not careful with types.

PHP doesn't compile so all errors become runtime errors.

Small correction: php IS compiled, just not the way we're used with the term. See https://thephp.website/en/issue/php-8-jit/ for more information.

The answers below show a good solution for this issue: use static analysis tools in build time and potentially even as a pre-commit hook.

Re: Everything you need (and don't need) to know about PHP's type system

#67

Post by asddubs »

nawarian wrote: post #64
asddubs wrote: post #52

Earlier quoted context omitted.

the only thing that sucks about strict typing is that there's no way to toggle it globally. so if you want to transition a codebase that's simultaneously actively being developed in other ways, you have to mess around with scripts that append it to the start of all php files/remove it again

Nothing that tools like Rector can't help you with. I believe this extra step is incredibly important, given most of your dependencies you won't control and forcing strict types to them is not very clever IMO.

I guess it wouldn't work if your dependencies weren't easily seperable from the rest of the code. in this case there are no dependencies, it's all custom cobbled together, for better or worse
Post reply on HN