> On 22 Oct 2014, at 21:11, Stas Malyshev <smalys...@sugarcrm.com> wrote: > >>> You propose to add completely new type conversion rules into the >>> engine, in addition to ones already present and used there. It's >>> not the same as merely changing how the engine internally runs >>> pre-existing code. The new rules are definitely becoming major part >>> of the language, not an implementation detail of some random >>> function like str_pad. >> >> No, they’re just a set of new validation functions. > > No, they are not. They are new engine primitives for handling type > conversions.
They’re not engine primitives. They’re a set of validation functions. Now, later as an optimisation, these might end up becoming opcodes if they’re used enough. Or, heck, this patch could do it. It doesn’t make a blind bit of difference how something’s implemented internally. If I get rid of all opcodes and replace them with function calls internally, that’s not a language change. The *language* has not changed. The way the Zend engine implements the language, in a way that is not user-facing, has changed. Are you opposed to the existence of ext/filter given it has FILTER_VALIDATE_INT, a “primitive for handling type conversions”? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
