Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58411
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.224.168.79 as permitted sender) client-ip=10.224.168.79;
MIME-Version: 1.0
In-Reply-To: <CAMyk_Ab3LO9erovz9XgF5q6ephm0=P3oGEKiqLCrKhk9d7bx7g@mail.gmail.com>
References: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
	<CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
	<CAJzDObeGJqtU2FdyfcdNdUO=eeXg6mOZ7iycbqwqH8unD_KxeQ@mail.gmail.com>
	<CAMyk_Ab3LO9erovz9XgF5q6ephm0=P3oGEKiqLCrKhk9d7bx7g@mail.gmail.com>
Date: Thu, 1 Mar 2012 08:55:47 -0500
Message-ID: <CAAyV7nH=NqiUiGmmh7BAoUabEDwon0o1E=y7XofUVPr+bg7QPA@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: Adam Jon Richardson <adamjonr@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: ircmaxell@gmail.com (Anthony Ferrara)

Please do not implement int, float, etc as an alias to scalar.  That's
going to cause nothing but trouble later on.  It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious ("I hinted for int, why is it a boolean?"), and
cause nothing but confusion.

If you only want to add a scalar hint, I'm fine with that (for now),
but please only add the scalar hint, no aliases...

Anthony

On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou <linepogl@gmail.com> wro=
te:
> Yes, I agree, the casting (or the failing to cast) has to happen on entry=
,
> for the reasons that you have very well explained.
>
> However, I cannot understand what it means to cast an object to a scalar.
> Does it always mean casting to string? Wouldn't that be slow in many case=
s?
> =A0Simple example:
>
> class A {
> =A0public $value =3D 1234;
> =A0public function __toString(){ return (string)$this->value; }
> }
>
> function foo( int $x ) { =A0// here "int" is used as an alias to "scalar"=
 as
> you suggest
> =A0return $x + 1;
> }
>
> $a =3D new A;
> foo( $a ); =A0// casting $a to scalar upon calling, as it is possible aft=
er
> all
>
> In this example, the integer value will have to be cast to a string only =
to
> be cast back to integer (unless something else happens under the hoods th=
at
> I am not aware).
>
>
> Lazare INEPOLOGLOU
> Ing=E9nieur Logiciel
>
>
> 2012/3/1 Adam Jon Richardson <adamjonr@gmail.com>
>
>> On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou <linepogl@gmail.com>w=
rote:
>>
>>> And, *what if PHP added the following aliases for the hint scalar*:
>>>
>>> - bool
>>>
>>> - int
>>>
>>> - float
>>>
>>> - string
>>>>
>>>
>>> If an object has a __toString method, does it qualify as a valid value =
to
>>> be passed to a scalar argument? In my opinion, it should.
>>>
>>> Your suggestion has a future compatibility problem. The introduction of
>>> new type casting methods (like __toInt or like __castTo) is an open
>>> possibility. In such a case, if those keywords are nothing but aliases =
for
>>> "scalar", then there will be no way to choose which type casting method
>>> should be chosen.
>>>
>>>
>>> Lazare INEPOLOGLOU
>>> Ing=E9nieur Logiciel
>>>
>>
>> You raise interesting points, Lazare, but I don't believe the
>> compatibility issues you're concerned about are valid.
>>
>> Failing fast, similar to the Poka-Yoke principal in manufacturing,
>> suggests that system failure should occur as soon as possible to reduce
>> software bugs:
>> http://www.martinfowler.com/ieeeSoftware/failFast.pdf
>>
>> Consider the following example:
>>
>> // example class that does not implement __toString()
>> class test{
>> =A0}
>>
>> function foo($arg1, $arg2, $arg3){
>> =A0 =A0if ($arg1) {
>> =A0 =A0 =A0 return "The answer is: " . $arg1;
>> =A0 =A0}
>>
>> =A0 =A0if ($arg2) {
>> =A0 =A0 =A0 return "The answer is: " . $arg2;
>> =A0 =A0}
>>
>> =A0 =A0if ($arg3) {
>> =A0 =A0 =A0 return "The answer is: " . $arg3;
>> =A0 =A0}
>> }
>>
>> $test =3D new test();
>>
>> echo foo($arg1 =3D "string", $arg2 =3D 100, $arg3 =3D $test); // echos T=
he
>> answer is: string
>> echo foo($arg1 =3D false, $arg2 =3D 100, $arg3 =3D $test); // echos The =
answer
>> is: 100
>> echo foo($arg1 =3D false, $arg2 =3D false, $arg3 =3D $test); // catchabl=
e fatal
>> error
>>
>> A developer using this function would only see this issue some of the
>> time, as this code fails late WITHIN some branches of the function, and =
the
>> bug is harder to identify.
>>
>> We can do better, though. If the scalar type hint were applied, users
>> would merely have to cast the object to a string ON ENTRY to the functio=
n
>> (and, of note, this would work for your __toInt and __castTo concerns):
>>
>> echo foo($arg1 =3D "string", $arg2 =3D 100, $arg3 =3D (string)$test);
>> // catchable fatal error
>>
>> Because the cast is performed on entry to the call, the bug shows up
>> immediately. I would argue that this code is clean (the cast to string i=
n
>> the foo() call is a small amount of noise/keystrokes), visibly conforman=
t
>> to the intentions of the foo() function, and more likely to catch bugs
>> early on in the process.
>>
>> Adam
>>
>>