Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80093
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: <CADyq6sJniodacHdmzEfOvN2FaTCHgTjLa8sCx41s_NQZ_kkLQg@mail.gmail.com>
Date: Fri, 2 Jan 2015 13:29:17 +0000
Cc: Stanislav Malyshev <smalyshev@gmail.com>,
 Thomas Bley <mails@thomasbley.de>,
 Nikita Popov <nikita.ppv@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A10AE57D-5304-4EC7-8D2E-6C593BD22502@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com> <20150101164402.EB1442605AB@dd15934.kasserver.com> <CADyq6sKN0PVdE5930YaSzZWkKwGM8SYbVrspzK_WL+7CRgK8hA@mail.gmail.com> <54A5DFCE.6030307@gmail.com> <CADyq6sJ6vsrzjQuWzzo3Th4WULNhrh-e=F2o7j7t1FysS9aAkg@mail.gmail.com> <458FFDA4-032E-46D9-BE93-E7307F98A1E6@ajf.me> <CADyq6sJniodacHdmzEfOvN2FaTCHgTjLa8sCx41s_NQZ_kkLQg@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)


> On 2 Jan 2015, at 13:15, Marco Pivetta <ocramius@gmail.com> wrote:
>=20
> The manual is wrong since it specifies a strict hint for something =
that is `mixed`. It is still useful tho, since it's telling us "it =
accepts" integer-ish values there. It's purely for documentation =
purposes though, it is by far dictating the actual implementation.

It doesn=E2=80=99t specify a strict hint at all. If this was Java, that =
would be a =E2=80=9Cstrict=E2=80=9D hint, perhaps, but this isn=E2=80=99t =
Java. Again, the C programming language has weak parameter types.

> No, argument types exist to prevent mistakes: they prevent invalid =
values to cross validation boundaries of the application. Documentation =
purposes are purely secondary, we already have phpdoc for that.

Again, this is not true in all languages. Simply because this is the =
purpose of parameter types in one language does not mean that it is the =
purpose of them in all languages.

> Again with the manual (*sigh*): the manual comes AFTER the code has =
been written.

So? I don=E2=80=99t see how that changes anything. The PHP manual=E2=80=99=
s conventions are well established and familiar to all PHP programmers.

Yes, it=E2=80=99s a manual, it=E2=80=99s documentation. But it has a =
well-established syntax for parameter types. Why should we deviate from =
it? Why wouldn=E2=80=99t new users be confused that the syntax used in =
the manual does something completely different for userland PHP code?

> The difference is that $amount must always be an integer (not =
integer-ish) value, whereas $value must be a stringable value, and the =
cast would happen at call-time, not at every loop (very relevant for =
instances of classes implementing `__toString()`, as the call happens =
only once).

Why must $amount, before entering the body of the function, be an =
integer? An integer that was converted from a float or a string would =
work equally well. Surely, in this case, you should make both arguments =
strict, for consistency?

> I think the example I just gave you is very consistent, explicit and =
easy to understand.

I don=E2=80=99t. I can=E2=80=99t understand why it=E2=80=99s fine to =
cast the second parameter, yet not the first. Why wouldn=E2=80=99t the =
following work? Let=E2=80=99s assume it follows the RFC, so int and =
string are weak type hints.

function repeat(int $amount, string $value) {
   $acc =3D '';
   $i =3D 0;

   while ($i < $amount) {
       $i +=3D 1;
       $acc .=3D $value;
   }

   return $acc;
}

What=E2=80=99s wrong with this function now? I don=E2=80=99t understand =
why $value should be weakly-typed and $amount shouldn=E2=80=99t be. Why =
should there be inconsistency here?

> If there is any mental burden, it's mainly introduced by the proposed =
RFC, whereas strict checking would remove any doubts about what $value =
can be.

But you=E2=80=99re proposing to have this RFC=E2=80=99s behaviour *and* =
have the strict behaviour. How is that less of a mental burden?

Thanks.
--
Andrea Faulds
http://ajf.me/