On Mon, May 21, 2007 9:57 am, Stefan Walk wrote: > On 21/05/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote: >> Latin capital letter A with diaeresis is 00C4. Not C4. > > Pay attention in maths, leading zeroes don't change a number.
Pay attention to documentation. Leading zeros change a number. <?php echo 0777, "\n\n"; echo 777, "\n\n"; ?> Output: 511 (decimal) 777 (decimal) Whether the 00 should be significant or not in any given computer syntax is arguable, and not really related to grade-school mathematics. >> And again you are suggesting me unportable solution. >> Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in >> test5.php on line 2 > > Tough luck. Unicode is a major change, no major change without > breakage. It could be made more compatible by using 'u' for marking > unicode strings and no prefix for binary strings, but most of the time > you want to handle text, not binary data, so that would be an > additional burden for the developer. If you definitely want to keep > supporting old versions, i'd suggest you use different files for > different versions and conditionally include them. Nightmare to > maintain, but that's another thing... This solution could make Unicode the death knell for PHP 6 deployment, rather than the killer feature to spur it... Do you really think software maintainers will put up with a nightmare of version-control-includes in their source?... Obviously you can't cater to just SquirrelMail, but it seems to me like the answer is simply not going to work out well for anybody with a similar portable application to deploy, and that's not good. >> I don't want to maintain different script version for PHP6 >> unicode.semantics=on. > > Well, /I/ don't want to see progress hindered by backwards > compatibility. Do you want to see PHP 6 not get adopted by the masses at all? How many people are still using PHP 4 a year and a half after 5 went stable? You think it's just cuz they're lazy, or it's because they can't migrate easily enough to make it worth it? You think something like this will actually help you realize your goal, or hinder it? [I'm guessing HINDER, in case that's not clear...] >> I'll wait for better documentation on unicode.*_encoding options and >> will >> see what I can do with them. > > Well, no encoding option will make "±" == "\xC4\x85"... > To see how unicode string handling works, you can have a look at > python. It's pretty similar... Note that my comments above are not about the minutiae of how to encode the bytes/units. It's about the Big Picture of needing to wrap every string function call or have multiple versions of PHP source which is just not a workable solution to any real-world developer. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
