Re: [RFC] [DISCUSSION] Scalar Pseudo-type

From: Date: Sat, 30 Dec 2017 22:14:15 +0000
Subject: Re: [RFC] [DISCUSSION] Scalar Pseudo-type
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-101460@lists.php.net to get a copy of this message
Am 30.12.2017 um 22:55 schrieb Michael Morris:
On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote:
Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP.
This is born of the fact that while ignoring datatype makes learning PHP easier, it makes using it harder - especially when testing.
and using type hints is completly opt-in at all
Mark me as against union types. First, it places the burden of getting the type right on the calling programmer. Stock PHP code doesn't do this and if popular 3rd party libraries start doing this too much it makes the language harder to learn.
but the outcome is way cleaner because errors are not silently as it is now without using type-hints - anyways, you are not forced to use any type hints at all but the people which know how bad code works without care about are able to do so and without unnions that all is very limited
Second it blocks this proposal, which is a way to give people who want to control types the ability to do so in their own code without creating BC breaks in PHP or interoperability problems with other libraries. Doing this requires declaring variable types as an OPTION. The default type of a variable will be scalar.
that is not true - even if the syntax would be BC compatible the behavior won#t
Under what I propose putting what is now a type hint on the function line will become a type declaration, and a casting operation will result if the wrong type is passed in. So function foo( int $a ) {} Obviously this path becomes unavailable to us with union types - and by comparison union types is an ineffective band-aid. The above is a shorthand for this function foo ( $arg ) { var int $a = $arg; } When a variable is declared this way it will autocast any assignment to the declared type. The only way to get around this is redeclare the type
this is hard to optimize - just look at the optimizations of PHP 7.1 also this ship has sailed long ago as we now have type hints (and i did not understand at all why they where intoruced in 5.3 only for arrays and objects) the point of union types is that you are not limited to "int or float or string" but can say "int or string both are OK, i hanlde that in my code" and so you can use strict_types with GET/POST or database results which are by defintion string but don't accept objects or arrays you can't handle proper function test(int|string $x) { $x = (int)$x; } currently without type-hints you have a "array to string conversion" insead fail and fix that at the caller where *obvisouly* nobody did realize that any random var froma request could be any array this has to be checked *before* call a function with such invalid data

« previous php.internals (#101460) next »