# PHP 6, backwards compatibility, and unicode.semantics - Thread: https://externals.io/message/37488 - Original archive: https://news-web.php.net/php.internals/37488 - Started by Geoffrey Sneddon on 2008-05-05T19:58:59+00:00 - Messages: 1 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #37488 — Geoffrey Sneddon — 2008-05-05T19:58:59+00:00 URL: https://externals.io/message/37488#37488 Hi, Over the past several months there have been various discussions about PHP 6, and backwards compatibility, and what that entails, and seeming it's come up again, I've finally written my thoughts: Unicode is probably the biggest change, and the one that has the most repercussions for backwards compatibility. If we maintain the unicode.semantics switch (which IMO absolutely must not be kept, regardless of which way becomes the default), then I, and others who have codebases sensitive to such things, will need to deal with four different cases in functions/methods: - Unicode argument, unicode.semantics=Off - Binary argument, unicode.semantics=Off (and PHP 5) - Unicode argument, unicode.semantics=On - Binary argument, unicode.semantics=On Ending up with four code branches to deal with such things is ludicrous. I can accept what I'm doing will be broken by Unicode, necessitating two code branches if it defaults to Off, or three if On (as I still need the binary/off one for PHP 5), but four is just insane. That said against the greater number of code branches, I do very much think we need to default to On, as there is currently no way to explicitly create a Unicode string (u'', for the sake of argument) without causing a compile time error on PHP 5 (allowing …'' at a compiler level would be good, IMO, and just throwing an E_FATAL when we actually try and parse it (which, if it in an if statement dependent on version, would be never)), except for doing something like unicode_decode("\x00\x00\xFF\xFD", 'UTF-32'), which gets horrible quickly (I already do that for cases when unicode.semantics is Off in some code I have locally, which really isn't fun). We already have b''. PHP 5.2.1 is pushing it enough for most projects, and adding a u'' to even 5.3 would be a bit too late. Realistically, the only way I can see happening is to default to On. Now, this means we don't have to care about code working on anything less than PHP 5.2.1 in many ways — also making it On by default means a fair amount of code will break — so the aim really should therefore be that code that currently works on PHP 5.2.1 doesn't need to work verbatim on PHP 6, but it must be possible to have code work on both PHP 5.2.1 and PHP 6, using (almost) all the new features of PHP 6, albeit branching with if statements to keep PHP 5 compatibility (using things like namespaces would inevitably push that up to PHP 5.3 and PHP 6). Now, taking the fact we don't need stuff to work verbatim, we can do all kinds of crazy cleanup (beyond the likes of removing magic_*, safe_mode, register_globals, etc.) like stopping dynamic methods being called statically, and visa-versa (IIRC, this is already in HEAD), as well as getting rid of deprecated stuff that's been around forever. Going back to Unicode briefly, there are some special cases regardless of the default, such as `chr()` — we need a way to have both binary and Unicode `chr()` functions (else we end up doing hell for Unicode, and something like unicode_encode(chr(42), 'UTF-8') (this matches the behaviour of `chr()` on the GNU userland). -- Geoffrey Sneddon