Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80538
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54B7BA74.4010708@gmail.com>
Date: Thu, 15 Jan 2015 14:20:08 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <0D1C9DE2-B639-44F7-897B-6F2D46D70387@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <54B7BA74.4010708@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hey Rowan,

> On 15 Jan 2015, at 13:02, Rowan Collins <rowan.collins@gmail.com> =
wrote:
>=20
> Zeev Suraski wrote on 15/01/2015 11:56:
>> PLUS have the ability to radically
>> change how it behaves based on a runtime option.  It's so bad that we
>> decided more than a decade ago that we want to refrain from ever =
introducing
>> such elements to PHP again (e.g. magic_quotes_runtime), and I'm not =
sure why
>> we're even discussing it.
>=20
> Just on this point, I do think declare() is potentially less evil than =
ini_set() / php.ini. A declare() directive is scoped to a particular =
section of code, so library authors shouldn't need to care which setting =
their users prefer, only the version they themselves wish to use. This =
contrasts completely with things like mbstring.func_overload, which =
makes shared library code run differently in different configurations.

Yeah, that=E2=80=99s the idea behind it. The hope is that you could have =
strictly-typed and weakly-typed code interact seamlessly with minimal =
issues. And, for the most part, this should allow that.

A large part of the motivation behind this was avoiding the problems =
that adding separate strict and weak hints would have. Inevitably, =
people who were fans of weak typing would use a weak hint all the time, =
and people who were fans of strict typing would use a strict hint all =
the time. There would also be the odd few who might mix them, but I =
don=E2=80=99t think that would happen terribly much.

It=E2=80=99s much easier to deal with this:

    foo(1.0, 1); // strict
    $qux =3D bar(=E2=80=9Cfoo=E2=80=9D); // also strict
    foobar($qux, baz(true)); // also strict

or this:

    foo(1.0, 1); // weak
    $qux =3D bar(=E2=80=9Cfoo=E2=80=9D); // also weak
    foobar($qux, baz(true)); // also weak

Than it would be to have to deal with this:

    foo(1.0, 1); // weak
    $qux =3D bar(=E2=80=9Cfoo=E2=80=9D); // strict
    foobar($qux, baz(true)); // baz is strict, foobar is weak

This RFC would guarantee that, for the most part, you=E2=80=99re dealing =
with the first case (strict mode) or the second case (default). I fear =
that separate strict and weak hints would result in the third case being =
commonplace.

I was also worried that if we just added weak hints, people who didn=E2=80=
=99t like them would not use them and instead use manual assertions. =
Similarly, I think something similar might happen if we just added =
strict hints. In both cases, you would be ending up with the third =
situation. Also bear in mind that if we added strict hints and did not =
change the behaviour of extension and built-in PHP functions, we=E2=80=99d=
 also be dealing with that third situation, since zend_parse_parameters =
essentially does a kind of weak typing.

Of course, this RFC does still lead to dealing with both weak and strict =
modes sometimes, but at least it=E2=80=99d always be the same mode =
within a given file, and by extension, within a given function, method =
or class. I think that=E2=80=99s more practical than dealing with two or =
more different modes within three lines of code.

> As has been clarified elsewhere on this thread, under this proposal a =
library author writing function foo(int $foo) will ALWAYS receive an =
integer, regardless of how that integer is arrived at. Very =
approximately, the declare() directive effectively gives the caller a =
choice between two pieces of syntactic sugar, both of which guarantee =
that the callee's contract will be met:
>=20
> if ( is_int($foo) ) { foo($foo); } else { raise_type_error($foo); }
>=20
> or
>=20
> foo ( (int)$foo );
>=20
> So, just to repeat, this is NOT like register_globals or =
mbstring.func_overload, because shared code never needs to handle both =
settings.
>=20
> That's not to say I'm 100% convinced that this is the right way to go, =
just that it's not as abominable as some people are making out.

Right.
--
Andrea Faulds
http://ajf.me/