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.godj...@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 <simonsimc...@googlemail.com>
> Date: 2012/2/28
> Subject: Re: [PHP-DEV] Scalar type hinting
> To: Arvids Godjuks <arvids.godj...@gmail.com>
> Копия: Michael Morris <dmgx.mich...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
