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

https://thephp.website/en/issue/php-type-system/

by nawarian • 6 years ago

115 66 6 years ago

untog2• 6 years ago

I have to say I’m impressed by how far PHP has come. I haven’t written any in years (well over a decade, even) but the commitment to improving a language many have written off as a dead end is laudable.

jonny3833• 6 years ago

PHP rocks in 2020. Couple it with laravel or something and you get a solid platform to build a monolith-type web app with really fast performance.

bnt• 6 years ago

Isn’t Laravel the worst performing framework out there right now, like even Rails looks like a viable option in terms of speed?

jonny3833• 6 years ago

Ruby is slower than PHP7+ by orders of magnitude. I doubt it.

noir_lord4• 6 years ago

Isn’t Laravel the worst performing framework out there right now.

I'm more of a Symfony than Laravel guy but I've done both enough to know that application architecture and environment configuration has more of an impact than either framework's "performance" does.

Silly things are slow in most web frameworks.

fraktl3• 6 years ago

No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously.

Any framework bears overhead, they all optimize programmer's time invested into solving the problem. It's cheaper to buy hardware and scale horizontally rather than swap languages and frameworks hunting for performance.

PHP being synchronous by nature is what limits its performance, but we have Swoole that fixes it and makes it faster.

For the ones who will google what Swoole is, some benchmarks I've done on my laptop show 5x (yes, 5 times, 500%) increase in performance when Laravel is ran via Swoole.

Can_Not• 6 years ago

The last time I looked at a rails-clone framework speed comparison chart rails was the slowest, with some Sinatra clones being the fastest.

noir_lord4• 6 years ago

It's gotten a lot better since I started using it ~2009 and now.

7.4 added typed properties. 8 is adding better caching, a jit and my favourite feature

    match()

https://php.watch/versions/8.0#match-expression

for all the enterprise heavy stuff I write a nicer cleaner and safer (by default) alternative to switch is going to make some code much cleaner to write and read and really that is what I care about more than almost anything else.

That it also returns a value is just the cherry on top. I am so tired of reading bad code with poor intent that has no comments and no documentation that's written in the most counter intuitive way.

admissionsguy• 6 years ago

The match expression is so elegant. For the past 10 years I've been puzzled by how verbose switch is.

untog2• 6 years ago

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.

gwillz2• 6 years ago

This is quite complete, definitely bookmarking for reference.

I've been knee deep in PHP for the last 6 months after keeping it at arm's length for probably 10 years. It's really quite incredible how much it's improved and I think the type system is the major factor for me. It's not perfect but damn - I can get some stuff done really quick now.

gwillz2• 6 years ago

I'll add though; the real benefit only comes with heavy use of objects, like in Yii/Craft. If you've got keyed arrays everywhere it's still a hellhole.

DJBunnies• 6 years ago

Arrays can become collections.

forgotmypw17• 6 years ago

While we are on the subject, does anyone know of a way of having required variable declarations in PHP, similar to the way Perl's "use strict" works?

This is one of my most common sources of bugs, and it is frustrating not having this be available, when it makes my life so much easier in Perl.

Lately I've been thinking about doing something crazy like implementing my own variable system...

notRobot• 6 years ago

Strict typing mode. In PHP the declare(strict_types = 1); directive enables strict mode. In strict mode, only a variable of exact type of the “type declaration” will be accepted, or a TypeError will be thrown. The only exception to this rule is that an integer may be given to a function expecting a float.

https://www.brainbell.com/php/strict-type.html

paledot4• 6 years ago

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

duskwuff• 6 years ago

Adding a static analyzer (like Psalm [1]) to the mixture makes PHP's types much more powerful. Psalm can use docblock annotations to attach more complex types to functions and variables, including:

* A "list" type representing a non-associative array

* Types representing specific kinds of values, like numeric-string or non-empty-array, as well as exact values as types (like true and false, or string constants).

* Typing on keys and values in arrays, e.g. array<class-string,int> for an array with class names as keys and integers as values

* Complex typing on the contents of associative arrays, e.g. array{foo:int, bar:string}

* Templated types on functions, like a function which returns an instance of a class whose name is passed in as a string:

    /**
     * @template T
     * @param T::class $class_name
     * @return T
     */

[1]: https://psalm.dev/

mhitza2• 6 years ago

Psalm is nice, however I would suggest PHPStan as an alternative for people that encounter a lot of friction with Psalm.

For example, in a project using doctrine I have to add a bunch of is null/@psal-mutation-free annotations. As all the methods can return null.

However, if Psalm had support for something like phantom types, maybe I could tag entities returned from the database for whom certain fields are guaranteed to have values.

slifin• 6 years ago

Adding Phan to this conversation initially created by the creator of a PHP, now in the hands of TysonAndre who does an insane amount of good work on it

muglug• 6 years ago

Psalm has levels – higher levels show fewer warnings (just like in PHPStan).

Maybe the `@psalm-ignore-nullable-return` annotation is more appropriate for those methods?

Do you use the Doctrine plugin?

osrec• 6 years ago

It actually makes me really happy to see more positive comments on a thread about PHP. It is an incredible workhorse, and doesn't get the credit it deserves.

I'm often amused by developers that revile PHP, while going on to use another language, which suffers from a similar set of problems to PHP, oftentimes with poorer performance and more complex toolchains.

PHP deserves a little more love, imo.

tutfbhuf5• 6 years ago

We often have comments like "actually php is not that bad" and then people might think let's give it another try, only to find out that they came across all over the same quirks of language (design) and runtime behavior again. I think the main problem of php is that it's so inconsistent. I would rather prefer a bad language if it would happen to be at least very consistently so.

bsdubernerd• 6 years ago

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-designed base and runtime library.

I'm still using PHP when it makes sense, in the same way I'm still using perl where it makes sense.

kyriakos• 6 years ago

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.

stunt3• 6 years ago

PHP has its special place for every developer that works on web. And it got all recent improvements thanks to all those criticisms. I think every popular language receives criticism and that's just fine.

I'm happy that the language is evolving and there is a strong ecosystem with quality libraries and developers unlike what it used to be 5 years ago.

I've been doing several languages (Scala, and Typescript. also Go recently) in last few years. But, I still follow PHP ecosystem closely and I'd definitely choose it for my next web startup. It's just 10x faster and ultimately cheaper to build web with PHP. That's why there are so many big success stories that started with PHP even in areas that you wouldn't believe. Surprisingly enough, not only web! One of Cloudflare's founders said on an interview that their back-end was written in PHP and it was used for a long time. That's one of the things that you think no one would do.

tutfbhuf5• 6 years ago

A static (serverless) website hosted on something like github pages or S3 paired with some API calls to an nodejs application running on a single core vm instance, both behind cloudflare, is also extremely cheap and should be able to easily beat php in terms of performance/costs ratio.

chx• 6 years ago

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 does not support explicit type definition in variable declaration -- PHP 7.4 however supports typed properties. https://wiki.php.net/rfc/typed_properties_v2

nawarian5• 6 years ago

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!

paledot4• 6 years ago

Important to notice that casting an array with numeric keys into an object is valid, but one can't dereference its value because property names may not start with numbers.

Not true, actually. The (admittedly obscure) syntax to access a property beginning with a numeral is `$obj->{0}`. Usually when this happens it's because someone was trying to be clever with JSON.

flir• 6 years ago

There's another way to get a variable starting with a numeral - abusing extract(), I think.

paledot4• 6 years ago

I've seen a few workarounds, each worse than the last, including casting back to array, round-tripping through JSON with the array flag set, and reflection. Hence the public service announcement that this is perfectly doable with the correct syntax.

aslamc• 6 years ago

Is there a good reason to still use php when you can use hacklang (https://hacklang.org/) which has much stronger type system. Some would even call it php++.

simonhamp• 6 years ago

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 Hack is on a different path which is potentially going to make it harder to share code between PHP and Hack.

PHP still has by far the larger community.

Given the choice today, I’d run with PHP.

asddubs2• 6 years ago

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

fraktl3• 6 years ago

Having "much stronger" type system cannot be anyone's definitive reason for deciding to go with Hacklang instead of PHP.

Type system doesn't guarantee that the programmer will utilize it properly, produce optimal code or even figure out the problem that is being solved by writing an algorithm.

You also need to pay attention to the ecosystem, problems that come with HHVM, the fact you're undoubtedly tying yourself with Facebook and what you're gaining / losing with the decision to go with a fork of PHP.

captn3m0• 6 years ago

Hack isn’t still commonly used outside of FB, and for the right reasons - the PHP community is much bigger. Very few projects test for Hack compatibility, and the performance gains aren’t worth it these days (they were 5 years ago, but not so much these days)

Shish2k• 6 years ago

If you’re building an app to run on other people’s servers, vanilla PHP is much more widely available :(

(Sad because I use Hack in my day job and PHP for my open source projects, and find Hack way more pleasant and productive)

thepratt• 6 years ago

Hacklang diverged from PHP proper a while ago, but I haven't validated what this actually means. I know interoperability wasn't guaranteed, but with Hack at your work are you able to use composer packages - i.e. Symfony components? The ecosystem around pure Hack packages or frameworks appears quite small/niche.

wolco3• 6 years ago

Main takeaway: strict types won't make your code faster!

It may make it slightly slower

fennecfoxen3• 6 years ago

The point of strict types is generally not speed, but rather, to make your code more correct.

chiefalchemist• 6 years ago

Correct? I'd probably say predictable.

choma• 6 years ago

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

nawarian5• 6 years ago

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

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

Related Stories