Re: [RFC] Scalar Type Hints v0.2

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