Hi! > 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.
Sorry, it's not "merely an optimization", it's making it an engine primitive, like (int) or empty() are. > 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?! is_long existed long before that, and nothing changed for it. 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. Saying "oh, we just add it like a random function and _only then_ we'll make it an opcode and it will be implementation detail" sounds a lot like gaming the system to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
