Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80547
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.82.175 as permitted sender)
Message-ID: <54B7DA71.1050905@seld.be>
Date: Thu, 15 Jan 2015 15:19:13 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: 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> <e131f1aaf3ae0491f958171df36211f5@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> <a939cd800e7472c135b4b0e5cc99e683@mail.gmail.com>
In-Reply-To: <a939cd800e7472c135b4b0e5cc99e683@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: j.boggiano@seld.be (Jordi Boggiano)

On 15/01/2015 15:10, Zeev Suraski wrote:
>> Except that is not the case for this proposal, which explicitly and
>> deliberately
>> prevents the directive affecting inclusion. The behaviour is impossible to
>> toggle at runtime, unless you’re using some weird extension which lets you
>> edit the flag on the ZEND_DO_FCALL opcode.
>
> Fact is that people who run websites where they don't care about strict
> typing, can end up viewing strict type failures coming from code they don't
> own, which would make the app fail 'catastophically' and unpredictably.
> You'd have no way to turn it off (without diving to and changing the file in
> question) - because it's the code itself that turns it on - and from the
> user's point of view, for all practical purposes, at runtime.
>
> I agree that the scope of breakage of using a local file definition is much
> reduced compared to an INI entry, but it's still there.

I agree that's a bad situation, but if a library uses strict types via 
declare, it is likely that it would also use scalar hints on its own 
method definitions. Not doing so would be irresponsible IMO as you'd 
indeed expose your API's users to strict failures.

If you do use strict types + scalar hints, a user passing random data 
from a non-strict file would never get a failure as the data would be 
coerced before reaching the strict library.

Right now, or with only weak hints, if a library decides to implement 
strict typing, they'll skip the scalar hints and check types with 
something like the assert lib [1]. A user calling it with random data 
would *always* get exceptions. There is no way for the library to use 
scalar hints to play nice with weak-typed callers as it would not be 
able to type check anymore in that case.

That is the value I see in the declare() proposal, although whether it's 
declare() or some other way to enable this per file I don't really care.

[1] https://github.com/beberlei/assert

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi