Hi,
The gettype() documentation warns people that the returned string is "subject to change". Why is there a function that's subject to change in the API?
And just to clarify: I agree is_() is better if we test for a certain type (as the note says). However, the use scenario for gettype() is when we do not test for a certain type (as in, we test for any type), which is less optimal when executed as 5-6 is_() calls.
Regards,
Stan Vassilev
The
gettype()documentation warns people that the returned string is "subject to change". Why is there a function that's subject to change in the API?
Probably because of the unicode stuff, might suddenly return "unicode"
(still true? don't know) or "binary" what was "string" before .. but
this is untested theory right now, but that's the kind of scenario they
mean here.
HTH
Hi,
The
gettype()documentation warns people that the returned string is "subject to change".
Why is there a function that's subject to change in the API?
Because life is complicated.
Because gettype("test") returns "string" in 5.x and "unicode" in 6.0.
What exactly are you trying to fix? And what exactly are you proposing?
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
From the user point of view it might seem that 5.x "string" and 6.x
"unicode" are all strings, whatever you call them. Still, I am sure
there is a background for the decision to distinguish between
"string" and "unicode".
2 марта 2010 г. 1:27 пользователь Antony Dovgal tony@daylessday.org написал:
Hi,
The
gettype()documentation warns people that the returned string is "subject to change".
Why is there a function that's subject to change in the API?Because life is complicated.
Because gettype("test") returns "string" in 5.x and "unicode" in 6.0.What exactly are you trying to fix? And what exactly are you proposing?
--
Wbr,
Antony Dovgalhttp://pinba.org - realtime statistics for PHP
--
--
С уважением,
Виктор
From the user point of view it might seem that 5.x "string" and 6.x
"unicode" are all strings, whatever you call them. Still, I am sure
there is a background for the decision to distinguish between
"string" and "unicode".
Yes, there has to be a difference between "string" and "unicode"
because otherwise you can't distinguish between binary goo and strings.
Derick
--
http://derickrethans.nl | http://xdebug.org
twitter: @derickr
From the user point of view it might seem that 5.x "string" and 6.x
"unicode" are all strings, whatever you call them. Still, I am sure
there is a background for the decision to distinguish between
"string" and "unicode".Yes, there has to be a difference between "string" and "unicode"
because otherwise you can't distinguish between binary goo and strings.Derick
--
http://derickrethans.nl | http://xdebug.org
twitter: @derickr--
So <PHP6, "this" is a string and in PHP6+ u"this" is a string and
"this" would be binary?
If PHP6 is unicode, then unicode strings are now the "normal" strings.
Binary strings are just binary data now. Maybe "string" and "binary
string" rather than "unicode" and "string".
So "string" is consistent across the PHP versions.
--
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Hi,
The
gettype()documentation warns people that the returned string is
"subject to change".
Why is there a function that's subject to change in the API?Because life is complicated.
Because gettype("test") returns "string" in 5.x and "unicode" in 6.0.What exactly are you trying to fix? And what exactly are you proposing?
If I have to propose anything, that'd be for 6.0 unicode strings to return
"string" and binary strings to return "binary", as that is more apt for the
real-world use cases people will find themselves in (and migrating code will
be easier).
A PHP user stumbled onto the "subject to change" note and asked if it's safe
to use. If differentiating both types of strings in 6.0 is what was
intended, then it's perfectly safe to use, and I'll probably file an issue
with docs to be more clear about the actual situation.
Regards,
Stan Vassilev