Re: __set_state (Was: Re: [PHP-DEV] [RFC] __debug_info())

Hi Derick, On Thu, Jan 23, 2014 at 8:30 PM, Derick Rethans <derick@php.net> wrote: > > > > Could anyone add __setState() for 5.6? > > > > > > Why would you want to do that? If at all, all the *newer* methods > > > should be __debug_info etc. __set_state was first and changing it to > > > __setState() would mean that var_export'ed() variables in < PHP 5.6 > > > would now no longer work? Or the other way around? It's a cosmetic > > > change that helps nobody—just like renaming other standard functions > > > to make them more "organised". > > > > I mean add alias for __set_state() to keep consistent names. > > __set_state() should be there very long time or forever for > > compatibility. > > You seem to misunderstand what __set_state() is for. It is for reliably > representing a value so that you can "include" it's contents with > var_export(). If 5.6 would suddenly start spitting out > Class::__setState() instead of Classs::__set_state() then older PHP > versions can't parse/include that outputted data anymore. > I have to check code, but don't we have options for this? We may use __set_state() for var_export and still have alias as __setState. People are using var_export exchange PHP data, so we should be careful. I agree this. > It's small cosmetic change, but it would assure PHP to be a good > > language to learn in the future. IMHO. > > But it makes as much sense as adding a str_len > I understand both opinion, strlen could be str_len. Other str function may be reamed. Some names are easy to decide, some are not. We may have list of votes for these. I'll make list after 5.6 release :) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net