Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80456
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <76F9DAD3-5A22-4A53-8262-CF6B33D80FC3@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
	<CAMUwpuR2QbvSoiKM=r_gc3hexvvTn0mxJ52hvkueRoGm3f8XXQ@mail.gmail.com>
	<76F9DAD3-5A22-4A53-8262-CF6B33D80FC3@ajf.me>
Date: Wed, 14 Jan 2015 13:10:50 +0200
Message-ID: <CAPhkiZw8FZy_fxp2-y=eRXsoqX7kyuda1z2TzhyOZHgx_BZU2g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: narf@devilix.net (Andrey Andreev)

Hello,

On Wed, Jan 14, 2015 at 12:22 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> Hi Julien,
>
>> On 14 Jan 2015, at 10:14, Julien Pauli <jpauli@php.net> wrote:
>>
>> Using declare() IMO, is a PITA.
>> Everything that can be done without the use of declare(), must be done w=
ithout declare().
>>
>> I would have prefered different syntax, like the ones we disccussed many=
 years ago , having strict checks with the foo(string $a) syntax, and non-s=
trict check with the foo((string) $a) syntax.
>
> Actually, this approach came about mostly to avoid that. I don=E2=80=99t =
really like the idea of mixing and matching weak and strict type checks. Ha=
ving some functions using (int) and (string), others use int and string, an=
d others still use both, would be confusing. Plus, it would mean that you=
=E2=80=99d be forced to follow the personal preference of the API authors.
>
> With this RFC, yes, you have to put an extra line at the top of the file.=
 But it has the advantage that everything follows the same behaviour, even =
extension/built-in functions. That=E2=80=99s what I like about it.

I don't understand why it should be a bad thing that the API author
forces rules on the consumer. The opposite is IMO fundamental to the
concept of an API - the rules specified by the author are a contract
that the consumer agrees to, and which allows for the whole thing to
work properly.

In this form, I don't get any benefit from strict type checks, because
I only want them so that writing foo(int $bar) guarantees me that the
caller *passed* an integer. Instead, I'd have to NOT use a type hint,
and instead do an is_int($bar) check inside ... this beats the whole
purpose.

This caller-controlled switch very much reminds me of
mbstring.func_overload, which I didn't care much for, until one day I
saw how it breaks all crypto code that authors had otherwise written
very carefully.

I prefer Julien's (int) $weak vs. int $strong syntax better (which is
what I've always wanted), but I don't care much if it's a declare()
statement, just as long as the author controls the behavior.
And while I'm on that - thank you for this proposal (specifically the
0.2 version), Andrea. Finally an RFC that allows both weak and strict
scalar type checks instead of the "can't go in both directions"
nonsense that has blocked this feature for years.

Cheers,
Andrey.