Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com>
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com>
 <CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com>
 <CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com>
 <CAAyV7nGQFrMoneDKvr0s1djOOkjn6rMj6PJcuB0842eA8EefOw@mail.gmail.com>
 <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com>
 <60744d7ea642fe03c7110502a3f4276a@mohiva.com> <CAAyV7nGZdq+TYU3eiQXj5CtEkRs84u_oOXRB7m+RNseU1QtG+Q@mail.gmail.com>
 <CAL0xaBHC8vFSnuezWwWqsBczHZA3uvgpb+K3z3z87Mc2Gbeseg@mail.gmail.com> <CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com>
Date: Thu, 8 Mar 2012 11:03:55 +0200
Message-ID: <CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.com>
To: Simon Schick <simonsimcity@googlemail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: arvids.godjuks@gmail.com (Arvids Godjuks)

Hi Simon!

2012/3/8 Simon Schick <simonsimcity@googlemail.com>:
> Hi Arvids,
>
> I pretty much like this idea as it's more strict. Let me say something
> to the questions you pointed out here.
>
> 2012/3/7 Arvids Godjuks <arvids.godjuks@gmail.com>:
>> I realize that with scalars it's not that straight forward, but
>> complicating things by adding an auto-cast syntax and so on is just
>> ridiculous. Hints should stay, well, hints. The only problem we have
>> is complications of accepting numerical strings or numbers as strings.
>> And what to do with "null".
>
> I'd like to handle it the same way as it's handled with the classes
> right now. If null is not the default-value you'll get an error when
> you pass null in there.
> One thing I'd like opened here: If you define a default-value
> different than null, should you be able to pass null as well and the
> compiler will use the default-value?
>
>> function a(bool $bool) {}
>> a(10); // Kill your self against the wall - write a(true);
>> If you define bool - use the damn bool!
>
> I like that. What should we do if this appears? As it's now - just
> throw an "Catchable fatal error" and let the script blow-up? I would
> go this far.

I think "Catchable fatal error should" be fine and users are familiar
with such mechanic because it already exists. Consistency, man,
consistency :)


>> I consider interchangeable only three cases:
>> 1. Numerical string.
>> 2. Integers and floats as strings.
>> 3. Integer and string =C2=A00 1 as bool.
>>
>> Any other cases should error out.
>
> Until now I thought about the weak variable-types as a order ...
> string, float, integer, Boolean.
> All Boolean values are compatible be an integer (0 or 1) and all
> integer are compatible to a float and so on. Do you think it's good to
> have it this way? This would mean that you could also get a Boolean
> true as string "1" ... I personally don't like that ... but I don't
> know where to draw the strict-line.
> Now think about that backwards. Can a "1" be passed as a parameter
> that expects Boolean? If yes, I'd keep it consistent in both ways.
>
> Bye
> Simon

That's a good tricky question, I like it.
Well, I think the lower should work just fine.
function a(bool $int) {};
a("1");

Because it's conversion to bool is straight forward. What of the
integer values [-=E2=88=9E, -1] and [2, +=E2=88=9E]? Really tricky question=
. From one
point of view they are a valid boolean true in the expressions. But
the question here is not if it's a valid boolean, but the fact that we
want our function to be passed with valid data and be more strict that
usual on what is passed to the function/method. So I would like to see
valid boolean values for a hinted argument these:

true
false
1
0
"1"
"0"

Simple and clear.




2012/3/8 Simon Schick <simonsimcity@googlemail.com>:
> Hi,
>
> Just a small addition to what I wrote about handling null ...
>
> function foo(array $d =3D array()) { var_dump($d); }
> foo(null); // This fails with the message: Argument 1 passed to foo()
> must be an array, null given
>
> As this code fails I'd not expect to change this behavior for the weak-ty=
pes.
>
> function foo(int $d =3D 20) { var_dump($d); }
> foo(null); // This should then also fail. Don't care about what's the
> default-value.
>
> Bye
> Simon
>

Totally agree here.
 I would even say that if you need a null as default value - that
can't be a type hinted argument, because it already has to accept two
different types of data and code inside has to handle that anyway. The
type hint is essentially useless in this situation. Adding something
like function a(null|string $a =3D null) kind'a silly and again is
adding unneeded complexity.





2012/3/8 Simon Schick <simonsimcity@googlemail.com>:
> 2012/3/8 John Crenshaw <johncrenshaw@priacta.com>:
>>
>> Conversion the other way is essential. Consider the following URL:
>>
>> http://example.com?foo=3D1
>>
>> In your PHP script $_GET['foo'] =3D=3D=3D '1' (a string).
>>
>> In fact, nearly every input to PHP is a string. This is why PHP was desi=
gned with some seriously robust type juggling on scalars. Any typing propos=
al that wants to actually pass a vote is going to have to allow appropriate=
 implicit conversions from string to other types.
>>
>> John Crenshaw
>> Priacta, Inc.
>
> Hi, John
>
> Ok .. the example with the get-parameter is quite good.
> You'll often have the case that you submit a string "0" or "1" and
> want to have it as boolean (f.e. if you have a dropdown with two
> options).
> Please keep in mind not to mix it up with checkboxes as unchecked
> checkboxes won't be sent back to your webserver :)
>
> Bye
> Simon

This is exactly the example for witch type hinting should not be used.
$_GET and $_POST data can be anything - string, number, array (lord,
how many scripts break into fatal errors when you just pass an array
instead of simple string). And passing data from these sources as
params to type hinted functions is a suicide. Type hints are meant to
filter input from external sources - that data should be passed
through filtering and validating layer - only after this you can work
with the data and passing it to type hinted methods and functions.

So I will remind to every one: Type hinting is not a filtering layer.
This is an instrument for designing a more strict internal layer and
prevent people passing unfiltered and insecure data to that layer. It
also helps to track the errors in code where invalid data slips
through the cracks. It also helps with the future optimization,
documentation generation and reflection. It does not mean that you can
now write only type hinted code - you can't and you shouldn't even try
(that will only make things unnecessary hard).

I have a very good relationship with array and object type hints right
now - they are used in a few key places, but their usage relative to
the whole application is not very wide. Same I imagine for the scalar
hints.