Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58409
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of adamjonr@gmail.com designates 10.182.31.47 as permitted sender) client-ip=10.182.31.47;
MIME-Version: 1.0
In-Reply-To: <CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
References: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
	<CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
Date: Thu, 1 Mar 2012 08:04:18 -0500
Message-ID: <CAJzDObeGJqtU2FdyfcdNdUO=eeXg6mOZ7iycbqwqH8unD_KxeQ@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=14dae93b590e15cb6b04ba2e196c
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: adamjonr@gmail.com (Adam Jon Richardson)

--14dae93b590e15cb6b04ba2e196c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou <linepogl@gmail.com>wrot=
e:

> 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 fo=
r
> "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{
}

function foo($arg1, $arg2, $arg3){
   if ($arg1) {
      return "The answer is: " . $arg1;
   }

   if ($arg2) {
      return "The answer is: " . $arg2;
   }

   if ($arg3) {
      return "The answer is: " . $arg3;
   }
}

$test =3D new test();

echo foo($arg1 =3D "string", $arg2 =3D 100, $arg3 =3D $test); // echos The =
answer
is: string
echo foo($arg1 =3D false, $arg2 =3D 100, $arg3 =3D $test); // echos The ans=
wer
is: 100
echo foo($arg1 =3D false, $arg2 =3D false, $arg3 =3D $test); // catchable f=
atal
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 function (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 in
the foo() call is a small amount of noise/keystrokes), visibly conformant
to the intentions of the foo() function, and more likely to catch bugs
early on in the process.

Adam

--14dae93b590e15cb6b04ba2e196c--