RE: [PHP-DEV] [RFC] Safe Casting Functions

> -----Original Message----- > From: Zeev Suraski [mailto:zeev@zend.com] > Sent: Wednesday, October 22, 2014 11:26 AM > To: 'Stas Malyshev'; 'Andrea Faulds' > Cc: 'PHP Internals' > Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions > > > -----Original Message----- > > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] > > Sent: Wednesday, October 22, 2014 11:18 AM > > To: Dmitry Stogov; Andrea Faulds > > Cc: PHP Internals > > Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions > > > > Hi! > > > > >>> - it's probably make sense to implement these function as a new > > >> opcode(s) in VM > > >> > > >> That could be an optimisation later, yes. I note that you’ve added > > >> function replacement with opcodes for certain commonly-used > > >> functions. We could make these functions use that. Then they’d > > >> still be usable as callbacks. > > > > 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. > > 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. > Introducing a new set of typing rules into PHP cannot be a 50%+1 decision.. 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. If we called them something like lossless_float() - that provides developers with the necessary heads-up that this will not use the standard conversion rules they're familiar with. It also gives them a good indication as to how it may be different from those standard rules. Changing the function names in a way that makes it clear that they don't represent the standard conversion rules, and providing a good hint as to how these functions behave differently right within the function names - would remove my objection to introducing these functions. In such a context, where they're not a part of the perceived core global namespace - I think they can be considered like any other extension, and be at 50%+1. Zeev