> On 22 Oct 2014, at 20:29, Stas Malyshev <smalys...@sugarcrm.com> wrote: > >> 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.
Yes, that’s still merely an implementation detail. If HHVM decides to make explode() into an opcode, it’s not a language change. It is not any different if PHP does the same. >> 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. So why is it a language change? > 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. > 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. …what? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
