Upcoming changes in PHP 7.1 | Hacker News Reader

Upcoming changes in PHP 7.1

dotdev.co

175 pointsdebrabyrd129 comments

I'm more excited by some features not detailed in the article.

Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat.

First, it's now possible to declare nullable return types (previously all return types did not permit null):

  public function getFoo(): ?int;

(You can also use ? on parameter and property types.)

Second, we now have a void return type for functions where there is no useful return value:

  public function handle(): void;

(Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.)

We're also getting type declarations for class properties:

  class Person
  {
      public string $name;
      public int $age;
      public bool $isEmployee;
  }

There's a few other things as well. The list() syntax (destructuring assignment) has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these). Also, trying to add non-numeric strings together with + now produces a warning (disclaimer: also me).

It's pretty amusing to read some of the PHP RFCs and see the verbal gymnastics taken to avoid saying "look, we're just taking this directly from Hack" :)

There's certainly a lot of stuff inspired by Hack. If Hack did something well, sometimes PHP copies it. The syntax of all PHP 7's new type stuff is very close to Hack's.

Though the details may differ significantly. Hack and PHP's type systems are only superficially the same (AOT rather than runtime validation, disabling or ignoring type checks versus using "weak" type checks, type inference vs. no type inference, etc.), for example.

Well, Hack was in turn based on PHP, so?

Some of this could also be attributed to the fact that Hack also borrowed heavily. While I'm sure a lot of it came from playing with Hack and saying "wow, this should be how PHP7 does things," it might also be recognition from use in other languages (Java specifically).

python, php, es6 ... Lisp did all before. (waiting for the smalltalkers to pitch in).

In a less facetious spirit, it's interesting to see languages converge a lot. Darwinian gene dynamics.

What's wrong with that? Hack was based on PHP, no? It's like CoffeeScript and JavaScript - lots of the incredibly useful features in CoffeeScript found their way into ES6.

What is the reasoning for type hinting void when the PHP manual specifies that a NULL value is returned if the return is omitted? http://php.net/manual/en/functions.returning-values.php

Self-documenting code. I'm already using return types wherever I can, and it's nice to keep things consistent.

Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.

I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.

It's a good point, and one which I personally hadn't thought about. The RFC specifically mentions it, so it's obviously a concern:

> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...

I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.

This is the same as other languages. In for example Java you have `public void method()`, and you then `return` which results in a `null`

Are you sure about that? I don't think you can use the results of void functions in Java as expressions.

This is completely incorrect. Java's null value is only valid as a value of an object type (e.g, Object x = null), and void functions don't return an object.

The compiler doesn't allow it, but if you call the function with for example reflection you get null.

Functions with a `: void` return type will still give you a NULL if you use them in an expression. I didn't want to break the property of existing PHP functions that they can always be used as expressions. I reasoned that your IDE or whatever can always warn you if you mistakenly try to use the result of such a function.

PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.

Even if you have a point it wouldn't matter because making void functions return something else than null would be a big (useless) BC break.

There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.

The point I was trying to make is that PHP does not have -- nor should it have, I think -- a concept of void. Functions without a return statement already return null. "return;" is already equivalent to "return null;" as well, as you pointed out. It would be more consistent to type-hint return null instead of introducing a new return type (void) into the language. I know PHPDoc already uses "@return void", and I have never liked it for the same reason. It is not a concept used anywhere else in PHP, AFAIK.

I think having a void return type makes a lot of sense, because it says "this function will never return anything but null".

You want to be able to communicate intent to clients of the function, especially with static tooling to check for common errors. For example:

https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...

... has an obvious code smell detectable statically:

https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...

> Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.

I'll take this opportunity to say thank you, for this, and all the other hard work you put into PHP internals.

I touched on the shortened [] syntax and non-numeric string arithmetic in the article.

Thank you for getting these added to the language, I think it's a fantastic improvement.

> has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these

Maybe you can answer this for me.

Will this work:

  $f = [$c, $d] = [1, 2];

i.e. set $c and $d to 1 and 2, then return the array and store in $f.

It should because:

    $f = list($c, $d) = [1, 2];

does exactly as you describe and this is literally just a shorthand syntax for accessing list().

Thanks. What about:

  $c = 2;
  $d = 3;

  $f = [$c, $d] = [1, 2];

Is $f: 2, 3 or 1, 2? I assume 1, 2 because if not then it's both an array constructor and destructurer at the same time which would be interesting.

Plus:

  $f = $c = $d;

is 3;

Let's break this up a bit, remembering that assignment is right-associative:

  $c = 2; # Assign 2 to $c
  $d = 3; # Assign 3 to $d

  [$c, $d] = [1, 2]; # Assign 1 to $c, assign 2 to $d

  $f = [$c, $d]; # Assign [1, 2] to $f

I'll be honest that I was firmly in the /r/lolphp camp for years, but PHP7 shows real promise. There's a real AST parser and the core team seems to be doing a lot to shore up the language.

I still think adding a string to a number should error instead of giving a warning, but one thing at a time. PHP7 and the future roadmap makes it look like PHP is on a path to not turning into Perl.

What do you think of the Perl 6 approach of providing both DWIM (weaker) and DWIS (stronger) typing?

* Numeric and string operators are kept distinct. For example `+` means numeric addition, never concatenation or some other string operation. To compare two strings, use `eq`, to compare two numbers use `==`. Etc. This sets things up nicely for supporting both DWIM and DWIS typing.

* DWIM typing: If you write something like `a + b`, you always get numeric addition. If need be the compiler tries to coerce `a` and `b` to numbers. `"12"` or `" 12" will both successfully coerce to 12. `"123foo"` and `"bar456"` will fail to coerce. If the coercion fails the program crashes at run-time.

* DWIS typing: To tighten type checking, add a type constraint. For example, `my Numeric (\a, \b) = ...` ensures that `a` and `b` only ever contain a numeric value.

From a grammar perspective, it seems odd to declare property types as prefixes instead of matching the return type syntax. Were suffixed types considered?

  class Person
  {
      public $name : string;
      public $age : int;
      public $isEmployee : bool;
  }

Well, we don't use suffixes for parameter types:

  public function __construct(string $name, int $age, bool $isEmployee);

And all other qualifiers (`static`, `public`/`protected`/`private`) come before the property name, so why should the type be any different?

Hack doesn't do this either.

I do think the idea came up.

This is just an excerpt from https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#....

My favorite feature is definitely the square bracket destructuring syntax. This is great for bringing tuple-esque operations to the language.

It doesn't bring tuple-esque operations to the language; it's a shorter alternate syntax for the already existing "list()" destructuring syntax.

But honestly with the shorter syntax it feels much more natural, compared to the weird "list" construct. Just an opinion though.

i dunno, i found that kind of special functions which are actually language constructs like list(), isset(), etc always ugly. Ok, some more syntax sugar to let these things not look like normal functions is of course an improvement, but i wish they would do some more radical changes to the language. Why not add multiple return values like in golang to achieve that syntax? Isn't exactly that list() should emulate in some way? Than deprecate that list() crap and throw it away in 7.2. But instead they will keep that list "function" forever along that new bracket syntax because they are afraid some code from the 90s would break. On the other hand they don't stop adding minor complete irrelevant changes that break existing code from yesterday.

That is a more comprehensive list. Thanks for sharing.

> Catching multiple exception types

> Support class constant visibility

Reminds me of what Rob Pike once said, "[Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more] are converging into a single huge language".

As someone who works predominantly with PHP and JavaScript, but has spent some time with Java, Ruby and Python - I actually agree with you!

Bob says "I wish PHP had this thing from Java" and Alice says "I wish Java had this thing from PHP". I don't think it's necessarily a bad thing.

It makes me really envious of those who went deep down the Lisp path and haven't had to look back. They don't have to spend time keeping up with the latest developments instead of pursuing some other goal, they have it all already.

PHP should actually renamed to Javascript, but there is already that weird Lisp like scripting language claiming that name. If u ask me, there is somethin wrong in our matrix...

Here is the real link: https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#....

PHP looks more and more like Java.

It can, though it doesn't have to, at all. PHP still has a very low entry barrier compared to Java. You can opt in to all of the syntactic sugar, or none at all, which is the way it should be.

Or Typescript...but that makes me happy. IDE help and type checking that code you haven't touched in months is so worth it

Not mentioned in the article: Several RFCs being voted on or discussed right now.

Also, https://wiki.php.net/rfc/libsodium

Off topic, but curious - Is there any discussion on whether there will be a support for a good concurrent programming in PHP in the future? (e.g. channels in Go & Elixir) - of course, you might say "you're using the wrong tool.."

React has been around for a while - http://reactphp.org/

This is not really concurrency, though, it just makes PHP resemble NodeJS.

I don't know if you can classify it as "good" concurrent programming but there's this https://github.com/krakjoe/pthreads

EDIT "pthreads v3 is restricted to operating in CLI only" - from the project page.

This one does look promising. I didn't know they re-written it for PHP7. But still looks like an early days. Might wait a bit!

If I were you I'd explore a language that goes beyond those low level concurrency constructs because they can be extremely tricky to get right. Clojure and Elixir would be my top choices and the final choice depends on the kind of system you're trying to build.

Using Redux with React or Vuejs is a good way to go!

There's amphp[1], and a community effort to make the different sync frameworks interoperable[2].

1: http://amphp.org/

2: https://github.com/async-interop

I haven't touched PHP in a long time, but the later releases makes me want to try it for a couple of small projects.

Is there any good introduction for people how "know" PHP4 and want to get started with PHP7, using best practises?

http://www.phptherightway.com might be of some help

I don't know PHP 7 yet, but I'd say there's plenty to learn just in PHP 5 if you haven't kept up since PHP 4. Perhaps a piecewise approach would be best, starting with the 'proper' C++/Java-esque version of OOP that I'd say is the biggest feature of PHP 5...

Nested try/catch/finally blocks won't lose return values anymore. Yay.

https://bugs.php.net/bug.php?id=72188

Supporting http/2 SERVER_PUSH seems cool at first glance, but doesn't it significantly increase the attack service for RCE vulnerabilities, being that it accepts arbitrary content from remote servers and passes it into a callback function?

It looks like PHP implemented SERVER_PUSH [0] via libcurl [1], openly described as a "work in progress."

I'm sure all the code is "well written", both in PHP and libcurl, but I can't shake the feeling that we'll see at least one significant vulnerability as a result of this new feature. The two github issues on the feature, one referencing a segfault caused by a double-free [2], and one caused by server-specific protocol issues [3], do not help to assuage my worry.

[0] https://wiki.php.net/rfc/curl_http2_push

[1] https://daniel.haxx.se/blog/2015/06/03/server-push-to-curl/

[2] https://github.com/curl/curl/issues/529

[3] https://github.com/curl/curl/issues/530

Deprecating mcrypt this way is clearly a mistake regardless of how ineffective it is as an extension or how unmaintained it is. Almost every framework I've seen makes use of it. In almost 9 years, it was not communicated to the community at all that this was based on unmaintained, buggy code, and now they just want to yank it in a minor upgrade? WTF? At the very least, there should be collaboration with people who maintain frameworks that use mcrypt as pretty much every major framework (ZF, Symfony, Laravel, etc.) does. This should be done in a major version upgrade like the one that just happened.

The release process specifically allows an extension to be deprecated and then punted to PECL.

As for frameworks, I and others have already been going around (for years before the mcrypt deprecation came up) switching things to use OpenSSL (and, for that matter, authenticated encryption) instead of mcrypt.

https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...

To date: ZF, CodeIgniter, Symfony, Laravel, and CakePHP all support OpenSSL instead of Mcrypt, as do many, many more.

You get E_DEPRECATED in 7.1 then in 7.2 you can still

    pecl install mcrypt

...if you really have a need to support abandonware.

Can we replace this with the link to the article it stole?

Anyone know if they are planning to fix ==, < and >? I kinda feel that declare(strict_types=1) could and should fix those without too much trouble.

Can we please change the link to the original article (https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#....)

"Learning Laravel" is a known plagiarist, who has a habit of ripping off content from other Laravel sites.

Yeah. I'll email 'dang in case he's not active at the moment.

It's just a summary of the post. Are Facebook and other sites doing something wrong as well?

It adds no value. It doesn't belong on HN; the original article on dotdev.co does, however.

The "ads by carbon" certainly don't cast this particular website in a good light, either.

It's not a summary of the post, it's just part of the actual post copied and pasted in.

Facebook and other sites make it clear that what you're looking at is a summary meant to lead you to another site - they don't disguise it as content.

Submitting a facebook post about a different post instead of the post itself is against HN rules as well, yes.

Don't you see the read more link? The author is listed there, too.

Don't ignore all the things.

I know you're trying to be clever, but seriously, please stop. He is a KNOWN plagiarist. All of his articles are copy-pasted from elsewhere (even if he does sometimes credit others in his posts).

He has even stolen content from other Laravel books and published it as his own book.

I don't get why they do it. Leave the fact that is unthetical, it's just annoying for users who can't read the whole post and at the same time very unproductive from a SEO perspective

I was wondering if that site was some sort of aggregator and amazed that it would carry over the code examples so well from the actual article. This explains so much.

I just checked their article again and now it's completely different. What a bunch of crooks.

Wow, yeah. They seriously rewrote it entirely and removed the source link just to maintain the traffic flow from HN? I'd say "flag the article".

EDIT: Dang to the rescue.

Ok, we changed the URL to that from http://learninglaravel.net/upcoming-changes-in-php-71. Thanks.

I'm saying this in the nicest possible way: I hate PHP and hope the project dies tomorrow. And it's funny because I use it at my job everyday. I suppose that's why I've grown to loath it that much. I should say that it is great for some things and it is very easy to stage and cheap to maintain, but it is a language from the previous century that has massively failed to adapt to current programmatic trends and patterns. And I shouldn't even start on its API, which to this day seems like the equivalent of a two year old child's drawing. Laravel and Eloquent made things a bit better, but still... Man, this language is a hot mess.

... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ...

... PHP 7.1 introduces visibility modifiers to constants ...

... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ...

... Example four contains numeric values, so everything else is stripped out, and the sum of those are used to calculate the total of 10. But it would still be nice to see a warning, as this may not be intended behaviour ...

Good to see PHP continues to introduce new inconsistencies while striving to break existing code by fixing old ones. Best of both worlds!

edit: OK this was uncharitable and technically some of them are not inconsistencies, just things I thought were weird. I know PHP is widely used and considered useful and will stay with us forever. But I found those snippets interesting.

Which inconsistencies are those? Functions that return; or don't return at all already return null in PHP.

I suppose its not an inconsistency as such, but I included it because I thought it was funny.

I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.

If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks.

Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types).

If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.

> If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code.

I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not?

EDIT: correction

Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie.

Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.

But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)

Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code.

Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.

I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.

Sure, it's not all-or-nothing, type checks that aren't enforced at runtime have some benefits, I just disagree that they can provide all of them.

If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.

I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.

I think one problem is when your object quacks like a duck, but the quack doesn't mean what you think it means.

Having methods that just have the right names is a pretty weak assurance, isn't it?

The type hinting is optional, so if you want "late type binding" you can just omit the type hints.

"Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.

Then... don't specify that you want a specific type?

PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system.

Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings.

That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.

7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.

> Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.

I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like

catch (Exception $e in (Exceptions...))

would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.

>I wonder why PHP includes more and more type checks and visibility features

Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..

So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..

To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....

https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...

> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification.

The good it does is it stops your application from possibly continuing on with buggy code.

This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.

Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.

This hot take is both pretty uncharitable and largely incorrect.

... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code

... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before

... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused.

... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of.

[0] even the few hits for https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22... are mostly false positives.

I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent.

|| is a short-cutting or comparison operator which returns the first true thing it encounters.

| is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets.

Semantically, | is absolutely the correct choice here.

A better question would be why there's a $2 there, though i hope that's just a typo and means $e.

Better yet, don't reinvent the world and just use commas?

Commas would require changing the syntax and implementation of catch. This way exception names just become first class subjects that can be combined with an overloaded operator.

Commas are used in PHP as a sequence of things, not multiple options. This single-pipe notation is already established as the further-up comments states.

> Commas are used in PHP as a sequence of things

Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.

This is correct. PHP makes extensive use of bitwise operators for function options. For examples, see json_encode, htmlentities, filter_input, etc.

I didn't understand why the remark was there at all. Honestly | reminds me of sum types and it's the perfect choice here.

The reason I added this was because most developers are used to using a double pipe when writing code that has 'or' conditions.

I understand the use of pipes for bitwise, but in this case if you read the code in the example, we're basically saying "if the exception is of type A or of type B", personally I'd be inclined to use || if I didn't already know the syntax.

> || is a short-cutting or comparison operator which returns the first true thing it encounters.

I wish. The fact that it actually doesn't is one of the things that really bugs me about PHP:

    <?php
    var_dump(0 || 42);

The above example will output:

    bool(true)

... ok, i gotta admit i had my Perl hat on for that reply.

You were actually correct -- see my above reply.

PHP does have the shorthand ternary operator `?:`, though, which does what you want here:

  $ php -r 'var_dump(0 || 42);'
  bool(true)
  $ php -r 'var_dump(0 ?: 42);'
  int(42)

Wow. OK, I am a big user of the ternary operator, but I hadn't come across omission of the middle part until now. To be honest, it's not the most accessible syntax (especially if you're coming from another language), but at least I have the option now - thanks!

edit: Just to clarify for anyone else unfamiliar with it:

    $ php -r 'var_dump(42 ?: 0);'
    int(42)

Depending on how far back you have to support (e.g., WordPress is still supporting 5.2), omission of the middle part wasn't supported until PHP 5.3.

5.3 came out seven years ago and isn't even officially supported by the PHP project now, let alone 5.2.

I know all too well, and you'd never catch me running that on any of my own systems. With a large enough install base, it's not uncommon to have a decent number of people on those older versions though.

Actually || is short circuiting and behaves exactly as he described, it returns the first true thing it encounters.

  $ php -a
  Interactive shell
  
  php > echo 1 || die('die');
  1

This echo's 1, it doesn't die.

Indeed it was a typo, i've now fixed that in the article. Thanks.

Reply on news.ycombinator.com