We at one time discussed some sort of default fallback encoding as far as I recall, and if that isn't defined, the default fallback would be the runtime encoding. I think it would ease migration headaches quite a bit I think if we could make some informed guesses on some of these functions that assume binary input arguments.
Even without adding a default encoding we could just assume runtime encoding and throw an E_STRICT. That would allow code to work unchanged but would also flag it as a potential problem area for someone to have a look at to make sure the assumption is correct. -Rasmus Andrei Zmievski wrote: > urlencode() requires binary because at the time we were discussing it, > we could not see what encoding to apply by default, since neither > runtime encoding nor output encoding quite fits. Perhaps we could do > something like another parameter that specifies the encoding to use, but > we won't be able to do it for other similar functions. > > -Andrei > > > On May 24, 2007, at 10:48 AM, Rangel Reale wrote: > >> I am testing my 25000 lines PHP5 application on PHP6, just to see what >> changes it would require. I changed exactly 5 (yes only 5) lines of >> code, and it worked perfectly except for the functions that requires >> binary string parameters with a (binary) typecast. >> >> What I am thinking is, if unicode_semantics=on, every single time I >> need to call urlencode (or other binary-only functions) with a >> variable, I need to typecast it. Well, if this is necessary 100% of >> the times, why not do this already inside urlencode, and if the string >> contains bad characters, give the same warning I get on the (binary) >> typecast on an incompatible string? I am just trying to think >> logically, I don't know the amout of work something like this would >> generate. >> >> If this is done, ate least 1 25000 lines PHP application will work on >> PHP6 with 5 line changes. I think this is great marketing for PHP6 >> migration. >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
