Re: [RFC] Change var_dump back?

From: Date: Sun, 25 May 2008 20:38:24 +0000
Subject: Re: [RFC] Change var_dump back?
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-37872@lists.php.net to get a copy of this message
Hello Geoffrey, Sunday, May 25, 2008, 10:29:54 PM, you wrote: > On 25 May 2008, at 19:28, Marcus Boerger wrote: >> now that we got rid of the unicode.semantics switch, should we change >> var_dump("foo") from showing 'unicode(3) "foo"' back to >> 'string(3) >> "foo"' >> as it is the new string type and change the other output to show >> 'binary' >> which it is now? > I'd say that var_dump("foo") should give 'unicode(3) "foo"' > and > var_dump(b"foo") should give 'binary(3) "foo"'. I see no reason > not to > give the explicit type — why would anything rely on this for backwards > compatibility? I would love to reduce the WTF factor: [marcus@zaphod php-cvs]$ php -r 'var_dump((string)"foo");' make: `sapi/cli/php' is up to date. unicode(3) "foo" [marcus@zaphod php-cvs]$ php -r 'var_dump((string)b"foo");' make: `sapi/cli/php' is up to date. unicode(3) "foo" [marcus@zaphod php-cvs]$ php -r 'var_dump(b"foo");' make: `sapi/cli/php' is up to date. string(3) "foo" [marcus@zaphod php-cvs]$ php -r 'var_dump("foo");' make: `sapi/cli/php' is up to date. unicode(3) "foo" In fact any normal person probably would expect that 'var_dump((string)"foo")' results in the type 'string' which I asked for and not something else. Same for 'var_dump(b"foo")'. Here I ask for a binary value 'foo' and having it report 'string' seems very wrong. It looks like we are always showing the opposite of what we have. > -- > Geoffrey Sneddon > <http://gsnedders.com/> Best regards, Marcus

« previous php.internals (#37872) next »