On Fri, Jun 7, 2013 at 9:27 PM, Gustavo Lopes <[email protected]>wrote:
> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans <[email protected]> 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.
--
Etienne Kneuss