> -----Original Message----- > From: Dan Ackroyd [mailto:dan...@basereality.com] > Sent: Wednesday, March 11, 2015 5:53 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > Voting no due to: > > i) Having conversion rules be difference in userland to internal > functions. > > You list 'Single Mode' as a benefit of this RFC, but it's only single mode > if you > gloss over this difference. This is a massive cognitive load, and will be > one of > those issues that catches users out again and again. Why on earth should a > boolean be convertible to int for some functions but not others?
Bool->int is not allowed across the board. Yes, in 7 internal functions will emit E_DEPRECATED and userland will reject, but that's a transition period but the rules are the same for both. > What will happen when someone writes code that extends an internal class > and overrides one of the functions, is that the person who is using that > extended class will have to alter their code to use the extended class in > a > different way to how they would use the built in class directly. > > For everyone who didn't pick this up in the RFC, it's hidden in the large > chunk > of text: > "Unlike user-land scalar type hints, internal functions will accept nulls > as valid > scalars." NULLs are a different case, that's true, but it actually can be resolved in the future (as is mentioned in the RFC). The key problem with rejecting NULLs for internal functions in the same way they are for userland is that this is the standard way you can denote an 'empty' argument. E.g., mysqli_connect(null, $username, $password). The problem is that function implementations rely on coercion of null->string and treat empty strings as if no argument was supplied. We can easily change it so that these function explicitly accept NULLs (which is already a supported modifier for ZPP), and then have explicit handling for NULL as a non-argument. Since it requires many changes in extension code - that's something that's probably too big for us to pull off for 7.0, but we can most probably do it for 7.1. Also, if we accept nullable type hints (https://wiki.php.net/rfc/nullable_types_rfc) the discrepancy will practically disappear, as you'd be able to denote an int/null hint in the very same way you can do it for internal functions. > ii) The subtle BC breaks. > > false -> int # No more conversion from bool > true -> string # No more conversion from bool That's fair; I think the breakage is very limited and worth the gains, but that's obviously subjective. Clearly, going for a single mode and making it stricter than what we have today does mean some level of compatibility breakage by definition - each person should form their opinion on whether that's worth it or not. > > btw You appear to have only tested this code against barebones > frameworks. These are often written far more cleanly than actual > applications so I don't think the report of 'very limited' BC breaks is > accurate. I don't view Magento, Drupal and Wordpress aren't barebones frameworks. They're pretty full featured real world apps (that also happen to be frameworks). > iii) Having conversion work, except when they don't. People who want weak > type hints want weak type hints - they don't want code that breaks > unexpectedly. > > function foo(int $bar){...} > > foo(36/$value); > // works when $value = 1, 2, 3, 4 breaks when $value = 5 > > This is neither weak nor strict type - this is a horrible hybrid that > would only > catch people out. Ultimately it's all about a signal to noise ratio. I think that strict STH has horrible signal to noise ratio; Weak type hints can easily allow problematic values to be glossed over and accepted - so there's zero noise, but also zero signal in case of trouble. This RFC proposes a rule-set that has very good signal to noise ratio, but of course, there are edge cases here and there. Personally, I don't feel that all the x div y examples that were/are commonly brought up in the context of float/int conversions are very real world, but rather, such edge cases - but here too, each person can form their opinion about it... It seems a key thing you don't like about the RFC is that it's transitional (what you call 'cleanup'). That's fair, but personally, I think that going through a transition period that on one hand allows both our codebase and more importantly our users' codebase to evolve - and that ultimately results in one, consistent language behavior is better than the alternatives (two modes that will never ever converge). Either way, thanks for the feedback! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
