On Mon, Jun 10, 2013 at 1:56 PM, Anatol Belski <a...@php.net> wrote: > Hi Etienne, > > On Mon, June 10, 2013 13:24, Etienne Kneuss wrote: > > On Fri, Jun 7, 2013 at 9:27 PM, Gustavo Lopes > > <glo...@nebm.ist.utl.pt>wrote: > > > > > >> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans <der...@php.net> > >> wrote: > >> > >> > >> That's the one where conversion int <> string for serialization was > >> > >>>> developed. It came into 5.5 with this patches (the originally > >>>> proposed patch is still attached to that ticket) > >>>> > >>>> http://git.php.net/?p=php-src.**git;a=commitdiff;h=** > >>>> 0ee71557ffd285552659b6aa37ea23**6e3bad493f<http://git.php.net/?p=php > >>>> -src.git;a=commitdiff;h=0ee71557ffd285552659b6aa37ea236e3bad493f> > >>>> > >>>> > >>> > >>> ["days"]=> > >>> - int(3) > >>> + string(1) "3" > >>> > >>> > >>> and > >>> > >>> - 'days' => 0, > >>> + 'days' => '0', > >>> > >>> > >>> I see this in all test cases - this is a BC break. > >>> > >>> > >> > >> I don't think this is a BC break, or at least it's a very minor. As I > >> understand it, when you read the property directly you still get an int: > >> > >> > >> $iv = "2008-05-11T15:30:00Z/2007-03-**01T13:00:00Z"; > >> $di = new DateInterval($iv); > >> var_dump($di->days); //int(437) > >> > >> So this applies only to var_dump() output, serialization output and > >> something exotic as an array cast (which anyway has its own > >> peculiarities wrt the key type conversion -- or the absence of it). > >> > >> > > So if I understand correctly var_dump now indicates a different type than > > what accessing the property returns? > > > > Even if the change itself does not constitute a big BC break, this > > behavior is confusing and seems like a big no-no to me. > > > > As I mentioned previously, that small piece is easy fixable, though it > possibly makes that place not portable between 32 and 64 bit.
This is the case for most string<->int conversions, isn't it? > The main > intention is to fix the unserialization crash, which IMHO interleaves this > small deviation. > Sure, I understand the intention. It's even more a new feature than a bug-fix at this point (as there are other ways to prevent this without actually implementing serialization). We shouldn't make the output of var_dump less consistent for something that feels as remote as serialization/unserialization, and especially if it is easily fixable. Best, -- Etienne Kneuss
