PHP looks more and more like Java.
Upcoming changes in PHP 7.1
11–20 of 137 posts
Re: Upcoming changes in PHP 7.1
#12... 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…
Which inconsistencies are those? Functions that return; or don't return at all already return null in PHP.
Re: Upcoming changes in PHP 7.1
#13... 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…
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.
Re: Upcoming changes in PHP 7.1
#14... 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.
Re: Upcoming changes in PHP 7.1
#15I'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;
Second, we now have a void return type for functions where there is no useful return value:
public function handle(): void;
We're also getting type declarations for class properties:
class Person
{
public string $name;
public int $age;
public bool $isEmployee;
}
Re: Upcoming changes in PHP 7.1
#16... 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…
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.
Re: Upcoming changes in PHP 7.1
#17... 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.
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.
Re: Upcoming changes in PHP 7.1
#18... 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.
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.
Re: Upcoming changes in PHP 7.1
#19I'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" :)
Re: Upcoming changes in PHP 7.1
#20Earlier 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 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.