Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80032
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: <54A466CB.9020400@gmail.com>
Date: Wed, 31 Dec 2014 21:28:20 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F4EB5BF5-E9B3-42C5-9291-88CB42A29207@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A466CB.9020400@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hey Stas,

> On 31 Dec 2014, at 21:12, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> I like it, it's consistent and to the point. If we must have scalar
> typed parameters (I'm not sure but if we do), IMO that's the way to do =
it.

Glad you like it.

> The issue is the class names though. E.g. see:
> =
https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/I=
nteger.php
>=20
> and:
>=20
> =
https://github.com/canaydogan/ObjectValidator/blob/master/src/ObjectValida=
tor/Validator/Int.php
>=20
> These are uppercase "I", but class names are not case-sensitive... So
> we'll need to figure it out. Unfortunately, looking at github,
> disallowing "class Int" looks like pretty bad idea. We can make it
> lowercase-only, but this would be a bit weird since it's not sensitive
> in all other places (unless we change that which is another huge can =
of
> worms).

Yeah, it=E2=80=99s a problem. I think some breakage here is inevitable, =
unfortunately. Some of the classes with these names are stand-ins for =
scalar type hints, so that code can =E2=80=9Cjust=E2=80=9D migrate to =
using actual hints. But this doesn=E2=80=99t apply to all of them.

We could choose to simply not prohibit them as class names, but that =
creates a weird inconsistency where you can make =E2=80=98class =
Integer=E2=80=99 yet =E2=80=98function foo(Integer $a)=E2=80=99 hints =
against the integer type, not your class. Type hints are very widely =
used, so I doubt this would help anyone, and we=E2=80=99d still be =
breaking existing code type hinting against such classes.

There=E2=80=99s not much we can do really. I suppose there is one =
positive outcome, in that hopefully when broken code is updated to work, =
it might have more descriptive class names. :)

> BTW, right now this code:
>=20
> function foo(integer $a) { var_dump($a); }
> foo(1);
>=20
> produces this message:
>=20
> Catchable fatal error: Argument 1 passed to foo() must be an instance =
of
> integer, integer given
>=20
> which is pretty confusing I'd say :) We'd probably want to rephrase =
that
> message (yes, I know, patching all those tests yet again=E2=80=A6)

We could rephrase it, but I don=E2=80=99t think it=E2=80=99s that bad. =
Once scalar hints are in, you won=E2=80=99t get that error any more. I =
think it could be worse as errors go, at least it distinguishes =
semi-clearly between objects (=E2=80=9Cinstance of integer=E2=80=9D) and =
other types (=E2=80=9Cinteger=E2=80=9D).

Thanks!
--
Andrea Faulds
http://ajf.me/