Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80501
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54B6BCEC.1080504@mabe.berlin>
Date: Wed, 14 Jan 2015 22:39:17 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <894A539A-1919-4368-8128-29863F411992@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <54B6BCEC.1080504@mabe.berlin>
To: Marc Bennewitz <dev@mabe.berlin>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Marc,

> On 14 Jan 2015, at 19:01, Marc Bennewitz <dev@mabe.berlin> wrote:
>=20
> 1. Inconsistencies of ZPP and explicit casts
>=20
> In my opinion it should be the same if you call a function in weak =
type mode and calling a function in strict type mode with explicit cast.
>=20
> But that would require to remove inconsistencies of ZPP and explicit =
casts.

Explicit casts and implicit casts have different behaviour, and that is =
definitely a good thing. Implicit casts can and should fail if the =
conversion isn=E2=80=99t sensible. Explicit casts aren=E2=80=99t =
supposed to fail.

> 2. Only one choice for the language
>=20
> In my opinion scalar types should be hinted strict and the caller of =
an API have to be sure to pass the right types. The caller have to know =
about the function he calls and he already should know what the function =
expects. This is the point were the caller have to know the type of an =
expected argument and he should know his own types. So he is the one how =
can pass the variable or make an explicit type cast.

This is all very well and good, and strict typing has its advantages, =
but there are a lot of people who do *not* want to have to deal with a =
strictly-typed API.

> 3. Reserved words
>=20
> I don't like it adding so much reserved words.

This doesn=E2=80=99t add any reserved words. It prevents the usage of =
some names for class names.

> As I understand it correctly the reservation is because of naming =
collisions on type-hints with scalars and classes/interfaces.
>=20
> Why not adding these types as classes (marked final and not allowed to =
be initialized for know)?

Because then you=E2=80=99d have to do this at the top of every single =
file:

use php\typehint\int;
use php\typehint\float;
use php\typehint\string;
use php\typehint\bool;

Considering how much people seem to dislike the idea of using declare() =
for strict typing, I can see how poorly that would go down.

More importantly, this would be inconsistent with our existing type =
hints like array and callable.

> 4. Only one naming
>=20
> I dislike the proposed aliases. The type names should be defined once =
without aliases and the manual and error massages should be changed to =
be consistent.

In an ideal world we would only have the short or long form, sure. But =
this isn=E2=80=99t an ideal world, and PHP doesn=E2=80=99t have =
compile-time validation of type hints. It would be too easy to write =
foo(integer $bar) and miss that it is broken if the function isn=E2=80=99t=
 called.

I don=E2=80=99t think having both int and integer is really a problem. =
It=E2=80=99s not going to cause confusion, they are obviously the same =
type. Coding style guides will mandate one or the other.

Thanks.
--
Andrea Faulds
http://ajf.me/