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. -- Etienne Kneuss
