Re: Scalar type hinting
| From: | Arvids Godjuks | Date: | Tue, 28 Feb 2012 22:56:20 +0000 |
| Subject: | Re: Scalar type hinting | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-58299@lists.php.net to get a copy of this message | ||
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data loss..
What just has to be done - the rule table when notices/warnings are thrown.
What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:
$a = 1;
echo gettype($a); // integer
$a = (int)"1";
echo gettype($a); // integer
$a = (string)1;
echo gettype($a); // string
And so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = "1";
It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.
So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.
---------- Forwarded message ----------
From: Simon Schick <simonsimcity@googlemail.com>
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Копия: Michael Morris <dmgx.michael@gmail.com>, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).
Bye
Simon