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

21–30 of 137 posts

Re: Upcoming changes in PHP 7.1

#21

Post by TazeTSchnitzel »

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

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.

Re: Upcoming changes in PHP 7.1

#22

Post by [deleted] »

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

[deleted]

Re: Upcoming changes in PHP 7.1

#23

Post by xiaq »

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

Re: Upcoming changes in PHP 7.1

#24

Post by naranha »

TazeTSchnitzel wrote: post #17
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.

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

> 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

Re: Upcoming changes in PHP 7.1

#25

Post by SilkRoadie »

naranha wrote: post #14
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 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 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.

Re: Upcoming changes in PHP 7.1

#26

Post by chrisseaton »

naranha wrote: post #20
vertex-four wrote: post #18

Earlier quoted context omitted.

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?

Re: Upcoming changes in PHP 7.1

#27

Post by TazeTSchnitzel »

naranha wrote: post #24
TazeTSchnitzel wrote: post #17

Earlier quoted context omitted.

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

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

Re: Upcoming changes in PHP 7.1

#28

Post by Mithaldu »

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

Re: Upcoming changes in PHP 7.1

#29

Post by zodiac »

naranha wrote: post #20
vertex-four wrote: post #18

Earlier quoted context omitted.

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.

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

Re: Upcoming changes in PHP 7.1

#30

Post by bpicolo »

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…

Better yet, don't reinvent the world and just use commas?
Post reply on HN