Hi, On Mon, Feb 2, 2015 at 6:39 PM, Andrea Faulds <a...@ajf.me> wrote: > Hey Derick, > >> On 2 Feb 2015, at 16:35, Derick Rethans <der...@php.net> wrote: >> >> On Mon, 2 Feb 2015, Dmitry Stogov wrote: >> >>> As I already told, in my opinion, version 0.1 was the perfect solution that >>> fit into PHP semantic very well. >>> >>> declare(strict_types=1); - is really weird solution. >>> It changes type hinting behavior per file scope, so, just to try strict >>> type hinting in a big project, people will have to change every single PHP >>> file. >> >> THis is why I believe it makes more sense to have this switch on the >> callee side, instead of on the calling side. > > That does have its advantages. But it also has some quite severe problems. > > For starters, if you set that flag on the callee side, you just broke > everything that uses that function and passes the “wrong” type. That’s a > migration headache. > > It also means that you don’t have any choice over strictness as the user of > an API: some APIs are strict, others weak. That means three lines of code > might use three different approaches argument strictness. I don’t like that > terribly much. >
As already said, we're just going around in circles at this point, but a migration issue? Whatever code using the scalar type hints should be *new* code in userland. You're basing your whole argument on the assumption that all internal functions would break with strict=1 ... nobody needs that and it doesn't have to be done. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
