Live data from Hacker News

Upcoming changes in PHP 7.1

dotdev.co

121–130 of 137 posts

Re: Upcoming changes in PHP 7.1

#121
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.

Re: Upcoming changes in PHP 7.1

#122

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 us…

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;
  }

Re: Upcoming changes in PHP 7.1

#123
post #19

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 us…

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" :)

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.

Re: Upcoming changes in PHP 7.1

#124

Earlier quoted context omitted.

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`

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.

Re: Upcoming changes in PHP 7.1

#125
post #83

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.

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.

Re: Upcoming changes in PHP 7.1

#126
post #83

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.

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.

Re: Upcoming changes in PHP 7.1

#127

Earlier quoted context omitted.

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.

Re: Upcoming changes in PHP 7.1

#128

Earlier quoted context omitted.

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.

Re: Upcoming changes in PHP 7.1

#129
post #45
post #23

> 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.

Re: Upcoming changes in PHP 7.1

#130

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 us…

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.

Post reply on HN