Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender)
Message-ID: <54B925B8.1010601@gmail.com>
Date: Fri, 16 Jan 2015 14:52:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
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> <CAPhkiZzj2b40cMD7H7uHNhF-LjeUF7XVhtLspib=_3+xAV8mYQ@mail.gmail.com>
In-Reply-To: <CAPhkiZzj2b40cMD7H7uHNhF-LjeUF7XVhtLspib=_3+xAV8mYQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: rowan.collins@gmail.com (Rowan Collins)

Andrey Andreev wrote on 16/01/2015 13:00:
> 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.

OK, point taken. I do think that it's a bad idea for library authors to 
do that, so don't think the language should make it easy, but I 
understand that some people want to do it.

Specifically, I don't think a library author should be able to tell me 
that, just because they're feeling picky, '42' and 42 are not equivalent 
when calling their function. It does very little to protect me from 
genuine mistakes (passing completely the wrong parameter), and makes my 
life as user of the library harder.

But then, fundamentally, that's the argument against having strict 
typing full stop, and it's painfully clear that there's a big divide of 
opinion on that.

Regards,
-- 
Rowan Collins
[IMSoP]