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

Upcoming changes in PHP 7.1

dotdev.co

Post reply on HN
Print view View original

31–40 of 137 posts

Re: Upcoming changes in PHP 7.1

#31

Post by coldtea »

elgenie wrote: post #19
TazeTSchnitzel wrote: post #15

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

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

Re: Upcoming changes in PHP 7.1

#32

Post by Mithaldu »

bpicolo wrote: post #30
Mithaldu wrote: post #28

Earlier quoted context omitted.

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

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.

Re: Upcoming changes in PHP 7.1

#33

Post by naranha »

TazeTSchnitzel wrote: post #27
naranha wrote: post #24

Earlier quoted context omitted.

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

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

Re: Upcoming changes in PHP 7.1

#34

Post by fredleblanc »

bpicolo wrote: post #30
Mithaldu wrote: post #28

Earlier quoted context omitted.

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

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

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.

Re: Upcoming changes in PHP 7.1

#35

Post by nkozyra »

elgenie wrote: post #19
TazeTSchnitzel wrote: post #15

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

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

Re: Upcoming changes in PHP 7.1

#36

Post by nkozyra »

SilkRoadie wrote: post #25
naranha wrote: post #14

Earlier quoted context omitted.

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.

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

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

Re: Upcoming changes in PHP 7.1

#38

Post by arenaninja »

Mithaldu wrote: post #28
codeulike wrote: post #9

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

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

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

Re: Upcoming changes in PHP 7.1

#39

Post by agumonkey »

elgenie wrote: post #19
TazeTSchnitzel wrote: post #15

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

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.

Re: Upcoming changes in PHP 7.1

#40

Post by arenaninja »

TazeTSchnitzel wrote: post #15

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…

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
Post reply on HN