Hello guys,
i had a chat with Dmitry this morning regarding the unpleasant state of
our test system. I assume here that everyone agrees that it is quite
difficult to provide each and every test expectations in two variants, one
for native string executoin (e.g. unicode_semantics=off) and one for unicode
execution (e.g. unicode_semantics=on). The easy way out is to have var_dump
not print 'unicode' for namely values but instead use 'string' always. Since
the encoding is meant to be transparent anyway there shouldn't be a problem.
And in case we have tests where the difference is important we can overwrite
the setting in the --INI-- setting and use the --UEXPECT-- as we are doing
now. Dmitry now came up with the idea of providing a new ini setting to
control this behavior. He suggests to name it "var_dump.show_unicode=on/off"
Any comments?
Best regards,
Marcus
Marcus Boerger wrote:
execution (e.g. unicode_semantics=on). The easy way out is to have var_dump
not print 'unicode' for namely values but instead use 'string' always. Since
the encoding is meant to be transparent anyway there shouldn't be a problem.
And in case we have tests where the difference is important we can overwrite
the setting in the --INI-- setting and use the --UEXPECT-- as we are doing
now. Dmitry now came up with the idea of providing a new ini setting to
control this behavior. He suggests to name it "var_dump.show_unicode=on/off"
Any comments?
Sounds like a good idea. BTW: I'm missing 5.0.5 and 5.1(0RC*|-DEV) QA-Spam.
Sebastian
It has nothing to do with the encoding. var_dump() outputs the value
type, which is 'string' for native strings and 'unicode' for Unicode
strings. I don't see why we should merge the two.
-Andrei
Hello guys,
i had a chat with Dmitry this morning regarding the unpleasant state
of
our test system. I assume here that everyone agrees that it is quite
difficult to provide each and every test expectations in two variants,
one
for native string executoin (e.g. unicode_semantics=off) and one for
unicode
execution (e.g. unicode_semantics=on). The easy way out is to have
var_dump
not print 'unicode' for namely values but instead use 'string' always.
Since
the encoding is meant to be transparent anyway there shouldn't be a
problem.
And in case we have tests where the difference is important we can
overwrite
the setting in the --INI-- setting and use the --UEXPECT-- as we are
doing
now. Dmitry now came up with the idea of providing a new ini setting to
control this behavior. He suggests to name it
"var_dump.show_unicode=on/off"
Any comments?Best regards,
Marcus
Hello Andrei,
transparent == doesn't really matter. And if you insist, will you write
all the tests and maintain them?
marcus
Thursday, October 6, 2005, 7:21:31 PM, you wrote:
It has nothing to do with the encoding.
var_dump()outputs the value
type, which is 'string' for native strings and 'unicode' for Unicode
strings. I don't see why we should merge the two.
-Andrei
Hello guys,
i had a chat with Dmitry this morning regarding the unpleasant state
of
our test system. I assume here that everyone agrees that it is quite
difficult to provide each and every test expectations in two variants,
one
for native string executoin (e.g. unicode_semantics=off) and one for
unicode
execution (e.g. unicode_semantics=on). The easy way out is to have
var_dump
not print 'unicode' for namely values but instead use 'string' always.
Since
the encoding is meant to be transparent anyway there shouldn't be a
problem.
And in case we have tests where the difference is important we can
overwrite
the setting in the --INI-- setting and use the --UEXPECT-- as we are
doing
now. Dmitry now came up with the idea of providing a new ini setting to
control this behavior. He suggests to name it
"var_dump.show_unicode=on/off"
Any comments?Best regards,
Marcus
Best regards,
Marcus