Re: Scalar type hinting

From: 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

« previous php.internals (#58299) next »