Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80582
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E81E632D-EE69-454A-86EC-31ED79EE1110@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>
	<D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me>
	<CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
	<A6B06BAB-F8C8-4BFC-98F5-21AD572D65A2@ajf.me>
	<CALrkBjbmKAiDw+UCJsnugWxChvBio5FUuuEOVcDS5FAqYNrStg@mail.gmail.com>
	<E81E632D-EE69-454A-86EC-31ED79EE1110@ajf.me>
Date: Thu, 15 Jan 2015 21:20:27 +0200
Message-ID: <CAPhkiZyLgfobNv_cRVvgDLfyETLYAk8dXJx6mm-D9-b2oZomWQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Mike Willbanks <pencap@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	Richard Quadling <RQuadling@gmail.com>, Leigh <leight@gmail.com>, 
	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)

Hi,

On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
>>  Now from that perspective I cannot rely that I am in strict and would h=
ave to handle the default weak even although I declared in my class that i =
wanted strict mode which only affected the code inside of that file.  That'=
s ultimately what I am saying and why I am stating it would have to handle =
both conditions.  In reality, you'd always act as if you were in a weak mod=
e supporting that case.
>
> I=E2=80=A6 really don=E2=80=99t understand, I=E2=80=99m sorry. Are you co=
mplaining that if a caller uses the weak mode, they are not bound by strict=
 types? Why do you want to affect the code of the caller?

Consider this badly designed API:

    declare(strict_typehints=3DTRUE);

    const MODE_APPEND =3D 0;
    const MODE_TRUNCATE =3D 1;
    const MODE_PREPEND =3D 2;

    function write_file(string $path, int $mode, string $data)
    {
        // it's quite obvious
    }

Somewhere else, you forget the parameters order ...

    declare(strict_typehints=3DFALSE);

    $path =3D '/important/file.dat';
    $data =3D '1 year';
    $mode =3D MODE_APPEND;

    write_file($path, $data, $mode);

It's a bad example - an awful (and indeed, very much useless) API,
combined with an absent-minded consumer. Yet, it demonstrates how
putting the caller in control *can* cause a disaster.

Of course, it is fair to say that this would be a very rare case,
where it is the author's fault for both being bad at design and
relying on a type-hinting feature that they don't understand, but it
is also fair to say that it is possible that a lot of people assume
that "strict_typehint=3DTRUE" affects definitions instead of calls (I
know I would, if I wasn't following this list).

But anyway, the point is - if you can't rely on it, why use it at all?
I guess if your goal was to use strict typing as a debugging tool
here, it makes *some* sense, but otherwise the way it works is
completely inverted.

----

What I would suggest is the '(type) $weak' vs 'type $strict' syntax
that was already mentioned.

I've said this before, during the previous RFCs discussions - all of
these proposals will fail, because they all suggest using the 'type
$whatever' syntax and that automatically upsets the "other camp",
whichever it is, but especially if the "other camp" is supporters of
strict typing. That's the moment when they become opposition, while
they could've otherwise not care because it's simply not their
"battle". If both are proposed to co-exist in a clean way (instead of
via a switch), I believe that we'll get substantially more positive
opinions from both sides.

And to hell with the "consistency" argument. Since when did PHP become
*that* concerned about purity and high consistency levels? Call this a
speculation, but barely a few people care for the the internal
functions' behavior - most of us will be happy if they stay as is
regardless of the kind of type-hinting that gets adopted. What we want
is the features (plural!), not the philosophy.

</rant>

Cheers,
Andrey.