Hi Derick,
On Thu, Jan 23, 2014 at 8:30 PM, Derick Rethans <[email protected]> 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
[email protected]