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:
[EMAIL PROTECTED] php-cvs]$ php -r 'var_dump((string)"foo");'
make: `sapi/cli/php' is up to date.
unicode(3) "foo"
[EMAIL PROTECTED] php-cvs]$ php -r 'var_dump((string)b"foo");'
make: `sapi/cli/php' is up to date.
unicode(3) "foo"
[EMAIL PROTECTED] php-cvs]$ php -r 'var_dump(b"foo");'
make: `sapi/cli/php' is up to date.
string(3) "foo"
[EMAIL PROTECTED] 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
