One thing I've been noticing, and I think we should be careful of in this
discussion, is making broad "....and this is what most people want"
statements. I've heard a number of people make some variation of that
claim now to support at-times radically different approaches. So, unless
most people want *everything*, including the things that directly
contradict one another, then I think it's safe to say that some of us are
giving in to the temptation to use hyperbole. It's understandable and I've
probably done it myself on more than one occasion. But I think we have to
be careful not to make such claims unless we actually have data to back
them up.
None of us can *credibly* state that one approach or another is supported
by "most people" or "most developers," etc. Unless somebody can product a
scientific poll on the subject, there is no clear majority consensus on
this. If there was, we wouldn't still be having this discussion after so
many years.
So please, let's all be careful not to make baseless claims about "most
(insert plural noun here)" supporting one idea or another. All it does is
add needless confusion and clutter to an already complex issue.
--Kris
On Tue, Feb 28, 2012 at 2: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
>
>
