Re: Scalar type hinting

Much of what you put forward here is why I don't want there to be a weak/strong divide. We can do "weak". Strong not so much. Current syntax allows $a = (int) 3; echo gettype($a); // integer $a = 'Hello'; echo gettype($a); // string. Under the new syntax this happens. int $a = 3; echo gettype($a); // integer $a = 'Hello'; E_WARNING raised echo gettype($a); // integer In other words, once the variable's type is declared, it WILL NOT CHANGE. If one doesn't want that behavior, don't declare a type, and things will work as they always have. On Tue, Feb 28, 2012 at 5:56 PM, Arvids Godjuks <arvids.godjuks@gmail.com> wrote: > 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