[Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Forgot to CC list. Original Message Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP Date: Mon, 21 Jan 2008 10:07:43 -0600 From: Jeremy Privett [EMAIL PROTECTED] Organization: Omega Vortex Corporation To: Antony Dovgal [EMAIL PROTECTED] References: [EMAIL PROTECTED] Antony Dovgal wrote: 6 reasons why we must to get rid of The Switch ASAP 1) it gives users false sense of compatibility when no compatibility is even planned; 2) it's supposed to mean compatibility, but can be changed only in php.ini, which means users would still have to maintain 2 versions of their software: one for On and second for Off. 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); 4) increases the maintenance costs a lot [2]; 5) this is yet another reincarnation of ze1_compatibility switch. I believe most of the people here agree it was a total failure - untested, unneeded and, most important, not working thing that complicates user's and developer's lives. Those who want compatibility may and will stay with PHP5 forever, those who need Unicode support will use PHP6. 6) we need to remove the switch ASAP and make PHP6 Unicode-only before people spend their time doing useless compatibility ports of their applications. --- [1] http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?revision=1.664view=markup Don't click this link if you want to sleep well today. [2] Here is a typical problem: http://bugs.php.net/bug.php?id=42861 Try to fix it without looking at the solution and you'll see what I mean. Seriously. +1 Thank you, Antony. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation Web:http://www.omegavortex.net E-Mail: [EMAIL PROTECTED] Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Forgot to CC list again. Just not my day. Original Message Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP Date: Mon, 21 Jan 2008 10:11:32 -0600 From: Jeremy Privett [EMAIL PROTECTED] Organization: Omega Vortex Corporation To: Geoffrey Sneddon [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Geoffrey Sneddon wrote: On 21 Jan 2008, at 14:38, Antony Dovgal wrote: 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
On 21 Jan 2008, at 14:38, Antony Dovgal wrote: 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? unicode and binary typecasts are not backwards compatible. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Tomas Kuliavas wrote: On 21 Jan 2008, at 14:38, Antony Dovgal wrote: 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? unicode and binary typecasts are not backwards compatible. I think the emphasis on the PHP6 release needs to be taken off the backwards compatibility and placed more on fixing what's broken about the current solution. If people need Unicode to the point that they're willing to make the jump to PHP6, then they'll do just that. It's terribly inefficient to try and make everything easy on everyone and your end result is hurting the internals developers for the sheer amount of headache that's being caused by the current implementation. You can't have it all, so instead of trying to make PHP6 backwards compatible, how about the focus be placed on making it BETTER than PHP5? -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? unicode and binary typecasts are not backwards compatible. I think the emphasis on the PHP6 release needs to be taken off the backwards compatibility and placed more on fixing what's broken about the current solution. If people need Unicode to the point that they're willing to make the jump to PHP6, then they'll do just that. It's terribly inefficient to try and make everything easy on everyone and your end result is hurting the internals developers for the sheer amount of headache that's being caused by the current implementation. You can't have it all, so instead of trying to make PHP6 backwards compatible, how about the focus be placed on making it BETTER than PHP5? over noisy standard string functions that require strict unicode/binary type checks - worse than php5 locale functions that report success even when locale is invalid - worse than php5 can't use same code in php5 and php6 - bad. Instead of making your code backwards compatible, you are forcing others to maintain two incompatible codebases. unicode.semantics is not php.ini only, it is PHP_INI_SYSTEM. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Tomas Kuliavas schreef: me, I'm all for dropping unicode.semantics - Antony makes strong points and it can only help the quality of the product if exceptions and switchable functionality is kept to a minimum. from a developers POV the same is true, additionally 'forcing' unicode on the masses will increase awareness and speed up the uptake of the necessary skills (imho). +1 for Antony's proposal over noisy standard string functions that require strict unicode/binary type checks - worse than php5 locale functions that report success even when locale is invalid - worse than php5 php6 is not even alpha stage yet AFAICT. lets give the devs a chance before jumping on these kinds of issues, no? can't use same code in php5 and php6 - bad. Instead of making your code backwards compatible, you are forcing others to maintain two incompatible codebases. unicode.semantics is not php.ini only, it is PHP_INI_SYSTEM. same difference. I don't see how 'having' to maintain two incompatible versions for different [major] php versions is effectively any different to maintaining two incompatible versions due to the unicode.semantics switch. given past experience with attempts to offer users a compatibility switch (as Antony pointed out) it is very likely that the result will be that you'll actually end up maintaining 3 incompatible versions: php5, php6 US=on and php6 US=off. another point to consider is that more than likely the take up of php6 will not be very fast - comparable to php5's take up in the face of php4. given that this is likely to be the case you will probably have a long grace period where you'll only need to support php5 - time which can be spend developing towards php6 without the hassle of having to deal with production users, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
