Re: why we must get rid of unicode.semantics switch ASAP
| From: | David Zülke | Date: | Wed, 23 Jan 2008 22:08:05 +0000 |
| Subject: | Re: why we must get rid of unicode.semantics switch ASAP | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-34898@lists.php.net to get a copy of this message | ||
How about allowing b"foo" in 5.3 (so people can start migrating their code early) and making unicode strings default in PHP7? :D
David
Am 23.01.2008 um 22:30 schrieb Andi Gutmans:
Hi Rasmus, Chris, I agree with you which is why I suggested to not have a switch but to make the default string binary and require u"foo" for Unicode strings. It supports the existing community incl. hosters and as Chris and you pointed out, the broad community of non-"high class" developers to who we owe PHP's success. As you rightfully pointed out the broader world isn't ready for it yet and we have to evolve at the same pace. I think that going down that route incrementally is exactly what's going to support that need. Let's face it, the people who are struggling today will have an immense relief when they get native Unicode capabilities in PHP 6 including a large amount of ICUs functionality. The u"foo" isn't what's going to take that away and PHP 6 will likely lead the pack in many regards when it comes to Unicode support. For the people who don't care today and will have to care tomorrow, they get to move to PHP 6 without much pain, they continue to benefit from their existing code and performance characteristics, and as they slowly evolve and find out that they do need to deal with it, it's there and readily available to them. Andi-----Original Message----- From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] Sent: Wednesday, January 23, 2008 11:29 AM To: Chris Stockton Cc: php-dev Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP I don't disagree with this, and that is actually why I insisted on having the unicode-semantics switch from the early days of the Unicode discussions, so you can blame me, again, if you consider it a bad design decision. My take on it was that just about all ISPs would run with Unicode semantics off and that the Unicode semantics on mode was more geared for large standalone applications and sites that wanted the luxury of working natively in their chosen character set without needing to always jump through hoops. If we get rid of the switch, then I agree that we can't make the default string IS_UNICODE. We would be crippling the implementation andtakinga step backwards in terms of leading the way in Unicode adoption. The longterm goal for just about everyone has got to be a "Unicode everywhere" approach. It used to be that the Web was primarily a Western single-byte charset phenomena, but that hasn't been the case for years. All major applications out there have implemented varioushacksto deal with these issues, some with more success than others. This is what PHP does. We take common Web development pains and trytoreduce them. Think back to the pains of XML parsing in PHP 3 and even in PHP 4 compared to today. Ultimately we need to get to Unicode everywhere, and the Unicode semantics switch was an acknowledgement that the world isn't quite ready for that yet. But it sounds like the world isn't ready for the switch either. Without it, I am afraid we will never get there, and that may just be something we have to live with. -Rasmus Chris Stockton wrote:justI partially agree, I have been watching this discussion and it'sfunnyhow we have such a class of high end developers saying to break old PHP code. But, the majority of the success of PHP is not due to this small class of high end developers, it's due to it's availability inashared hosting environment, and the ease of use for beginners, andtheoodles of fairly poor quality code that is easy to copy and pasteontopeoples websites. Look at the adoption of php4, many webhosts haven't even updated to PHP5 completely due to things like register_globals and small backwards compatibility breakage. The list of problems is small and correctable, if you give system engineers at all of these hosting companies the choice of A. Upgrade to php6 and drive support calls through the roof, or B. Stay at PHP4/5 for eternity until a more (insert your complaints / rants here) language comes along todethronePHP. Problem is, PHP has been built to great success based on it's early foundation, but now a group of high class developers want it to be more then PHP was built onto. You will sacrifice it's success if backwards compatibility is not just, broke, but obliterated. Why change PHP's philosophy? Keep it easy for the new user, keep it successful, and make me work a little more when I want to implementmy"high class" development methodologies. I don't mind, I do italready.I write this as a "high class" developer. -1 -Chris On Jan 22, 2008 7:32 PM, Richard Lynch <ceo@l-i-e.com> wrote:On Mon, January 21, 2008 8:38 am, Antony Dovgal wrote:6 reasons why we must to get rid of The Switch ASAP ----------------------------------------------------I was +1... Until folks started posting that old PHP scripts won't run as-is in PHP 6?... That's just daft... When my webhost upgrades to PHP 6, I need all my old scripts to-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpakeep on chugging away, as much as possible... I really think we're stuck with the default "string" being an old-school binary string, unless you want to lose a LOT of users in-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phphurry, or have PHP 5 stick around forever and ever. -- 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/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php