> On 22 Oct 2014, at 09:17, Stas Malyshev <smalys...@sugarcrm.com> wrote: > > If those are opcodes, those rules will require 2/3 majority for > acceptance, since those will be the engine rules for type conversion, > not just a set of functions. And, of course, the rules not matching the > other engine rules for type conversion, sorry for sounding like broken > record.
No, it wouldn’t require a 2/3 majority. The optimisation me and Dmitry are referring to is merely an optimisation, it’s an implementation detail. This doesn’t touch any of the language spec or the language as understood by users. Or would you argue that the fact is_long is now an opcode is a language change, and Dmitry should’ve made an RFC before making a change that is completely non-user-facing?! > On 22 Oct 2014, at 09:26, Zeev Suraski <z...@zend.com> wrote: > > Regardless of how we implement it, this requires a 2/3 majority - it'll be > perceived as an integral part of the core language in the same way that > gettype() and is_array() are considered parts of the core language. Sure, but so is all of ext/standard really. If you got rid of ext/standard, PHP wouldn’t really be PHP. Yet there is no such barrier to entry for ext/standard. > Introducing a new set of typing rules into PHP cannot be a 50%+1 decision. It’s not a “new set of typing rules”. It’s a set of convenient conversion functions. Would adding ext/filter have required 2/3 majority? Because it has its own set of “typing rules”. > On 22 Oct 2014, at 09:34, Zeev Suraski <z...@zend.com> wrote: > > Thinking a bit more on this, if we don't want the 2/3 hurdle and perhaps > make this a bit (or actually a lot) less controversial, we should change the > names of these functions. to_float() strongly implies that this function > represents PHP's standard typing ruleset, which these functions do not. I’m wary of making the names much longer. The less convenient they are, the less likely they’ll be used… so the less likely the primary goal of the RFC would be achieved. Also, we already have intval, floatval and strval. I think people will notice the fact they were introduced in PHP 7 and the fact they’re not aliases of those, and perhaps realise they’re different. If they just followed the “standard conversion rules”, why would they exist given the existing functions for that? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
