> -----Original Message----- > From: Shashank Kumar [mailto:shashankkumar...@gmail.com] > Sent: Wednesday, February 25, 2015 2:54 PM > To: Dmitry Stogov > Cc: Anthony Ferrara; internals@lists.php.net > Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5 > > On Wed, Feb 25, 2015 at 4:30 AM, Dmitry Stogov <dmi...@zend.com> > wrote: > > As I understand the proposal and above example, it's possible to change > the > 'strict_type' settings per file. > So, for an enterprise application being developed over many years, it's a > very > realistic scenario that this setting will be different in different files > especially > if coding conventions are not followed (happens very often). > > Does that mean when reading or writing code, in addition to checking the > signature of a function, I have to check the 'strict_types' setting at the > top as > well, to understand how that signature behaves?
Not quite; You need to check the strict_types setting not where the function is defined, but where the function call is being made. It means that if you're editing other people's code, you first need to check what mode you're at, as it will determine the semantics of function calls in the file you're editing. Independent of the issues I see with strict types themselves, I think the concept of a dual mode has two substantial disadvantages: - It's an extra element to worry about when determining what your code will behave like. Yes, it's self-contained in the file - which is an advantage of INI entries, but it's still another thing to worry about. - As your question suggests, I think we have substantial evidence that the nature of this dual mode will be confusing to users. And we're not talking about the average users - we're talking about internals@ subscribers, some of which are big community leaders (sorry Matthew :). Combined, it's additional cognitive burden on the developer base, and it may also be divisive (e.g. "I only use libraries written with strict mode" or vice versa). That's why in the Coercive RFC we sought to find a combined ruleset that does away with these disadvantages, while doing its best to cater to the key needs of both camps, with the endgame being having just one camp. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
