Re: [RFC] Change var_dump back?
| From: | Marcus Boerger | 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