Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80641
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54B90431.10903@gmail.com>
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>
	<54B90431.10903@gmail.com>
Date: Fri, 16 Jan 2015 15:00:41 +0200
Message-ID: <CAPhkiZzj2b40cMD7H7uHNhF-LjeUF7XVhtLspib=_3+xAV8mYQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: narf@devilix.net (Andrey Andreev)

Hi,

On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> Mike Willbanks wrote on 15/01/2015 16:55:
>>
>>   It also means that then a library developer would
>> need to handle conditions on both sides (when in weak vs. strict).  So I
>> don't really understand where the gains of this would come from and it
>> actually causes me concern in that what if a developer forgets to define
>> strict and you're entire system is built on strict.
>
>
> In case this hasn't been repeated enough times already: No They Would Not.
>
> As a library developer, you do not rely on strict or weak hints, you rely on
> the variables you receive being of the types you require. This is guaranteed
> in both modes.
>
> You cannot stop the user of your library doing whatever it takes to get past
> your validation. It is up to them to provide sane inputs to your published
> API, and no version of type hinting can change that.

This is mostly true, but relying on the variable that you receive
inside a function is different from relying on the variable that gets
passed to a function.

Yes, there will be users who will simply do an explicit cast, but
there will also be users who will take notice of the produced error,
and ask themselves why first, instead of immediately trying to
"override" it.

Many developers want to do that, regardless of the reasons why. Some
just like the strict philosophy better, some see it as a way of
educating their users, and others use it sparingly. Try arguing with
anybody writing crypto code and they will all tell you that any case
of uncertainty must be handled with a *hard* failure.

You may not agree that it is necessary, but that doesn't make it
invalid. And intentionally allowing only one guaranteed behavior does
imply that the other is invalid.

For the Nth time - if I want to achieve that effect, I will code for
both cases by not using the feature and doing is_int(), is_string(),
is_bool(), etc. checks, so the language might as well help me do it. I
would understand if it was not helping with something that's just
wrong, but this is not the case at all here.

Cheers,
Andrey.