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

From: Date: Thu, 23 Jan 2014 21:51:28 +0000
Subject: Re: __set_state (Was: Re: [PHP-DEV] [RFC] __debug_info())
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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]


Thread (30 messages)

« previous php.internals (#71467) next »