Re: [PHP-DEV] Unicode Implementation
Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing to share with you guys... PHP6 is a major release. BC is a priority, but as far as I'm concerned not the top priority. I wouldn't mind a unicode-only PHP at all. Like a few others here, I think the speed penalty won't be huge at all. It's not like my scripts are 90% string handling (and I assume the unicode benchmark scripts are). I wouldn't want you guys having a messy codebase just because you want to support non-unicode and unicode. I also wouldn't want you guys branching to a non-unicode line of PHP releases. It would just be too much. As far as I'm concerned, I'd be fine with a unicode only PHP6. Unicode is progress. I think a lot of the people who don't want it, don't yet see the positive things it brings. Ron Peter Brodersen [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals [EMAIL PROTECTED] (Adam Maccabee Trachtenberg) wrote: We seem to be under the impression that the Unicode speed penalty will be so harsh that a Unicode-only PHP 6 will be too slow for use. However, we don't know that for sure. Yes, it will be slower, when you look at the whole request cycle, it may not matter. I agree - the speed penalty comparsion seems mostly related to php scripts that does nothing else than handling strings. I recall the old discussions (echo vs print vs ?...? ) using similar benchmarks. It is true when you compare the specific functions/language constructs the relative difference in speed is apparent. But compared to a bunch of other functions that you'll usually use (database connections, file access, data sorting, etc.) I imagine that the speed penalty is simply marginal. Just my 0.02 \x20B1. -- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Ditto please! Jevon - Original Message - From: Ron Korving [EMAIL PROTECTED] To: internals@lists.php.net Sent: Thursday, October 13, 2005 8:27 PM Subject: [php] Re: [PHP-DEV] Unicode Implementation Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing to share with you guys... PHP6 is a major release. BC is a priority, but as far as I'm concerned not the top priority. I wouldn't mind a unicode-only PHP at all. Like a few others here, I think the speed penalty won't be huge at all. It's not like my scripts are 90% string handling (and I assume the unicode benchmark scripts are). I wouldn't want you guys having a messy codebase just because you want to support non-unicode and unicode. I also wouldn't want you guys branching to a non-unicode line of PHP releases. It would just be too much. As far as I'm concerned, I'd be fine with a unicode only PHP6. Unicode is progress. I think a lot of the people who don't want it, don't yet see the positive things it brings. Ron Peter Brodersen [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals [EMAIL PROTECTED] (Adam Maccabee Trachtenberg) wrote: We seem to be under the impression that the Unicode speed penalty will be so harsh that a Unicode-only PHP 6 will be too slow for use. However, we don't know that for sure. Yes, it will be slower, when you look at the whole request cycle, it may not matter. I agree - the speed penalty comparsion seems mostly related to php scripts that does nothing else than handling strings. I recall the old discussions (echo vs print vs ?...? ) using similar benchmarks. It is true when you compare the specific functions/language constructs the relative difference in speed is apparent. But compared to a bunch of other functions that you'll usually use (database connections, file access, data sorting, etc.) I imagine that the speed penalty is simply marginal. Just my 0.02 \x20B1. -- - Peter Brodersen -- 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
Re: [PHP-DEV] Unicode Implementation
And remember: PHP6 will not be released for at least a year. So by then typical servers will run at several hundred MHz more, so perhaps the speed penalty won't be noticed at all. This is even more true compared to the current speed of PHP as there will (If I recall this correctly) be significant performance enhancements of the Zend Engine with the switch from 5.0 to 5.1. OLLi No self-respecting man in Iowa goes anywhere without beer. [LOST 122] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Oliver Grätz wrote: And remember: PHP6 will not be released for at least a year. So by then typical servers will run at several hundred MHz more, so perhaps the speed penalty won't be noticed at all. And people will do more with PHP ultimately making the MHz boost irrelevant. Despite tremendous increases in hardware performance, the software we run seems to run slower and slower. This is even more true compared to the current speed of PHP as there will (If I recall this correctly) be significant performance enhancements of the Zend Engine with the switch from 5.0 to 5.1. PHP 5.0 is MUCH slower the PHP 5.1, all PHP 5.1 does is bring the performance back on part with 4.X in most cases (not all, even) when used in conjunction with an opcode code cache such as APC. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Thu, 13 Oct 2005 17:43:03 +0200 [EMAIL PROTECTED] (Oliver Grätz) wrote: And remember: PHP6 will not be released for at least a year. So by then typical servers will run at several hundred MHz more, so perhaps the speed penalty won't be noticed at all. This argument is irrelevant. You only hide the possible lack of scalability behind hardware improvements. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Ilia Alshanetsky schrieb: And remember: PHP6 will not be released for at least a year. So by then typical servers will run at several hundred MHz more, so perhaps the speed penalty won't be noticed at all. And people will do more with PHP ultimately making the MHz boost irrelevant. Despite tremendous increases in hardware performance, the software we run seems to run slower and slower. Which doesn't stop them from moving from PHP to Ruby (which I suppose is slower than PHP will ever be). I know that more power is always eaten by more complex software but this is not valid for ordinary applications. This is even more true compared to the current speed of PHP as there will (If I recall this correctly) be significant performance enhancements of the Zend Engine with the switch from 5.0 to 5.1. PHP 5.0 is MUCH slower the PHP 5.1, all PHP 5.1 does is bring the performance back on part with 4.X in most cases (not all, even) when used in conjunction with an opcode code cache such as APC. The microbenchmarks on http://www.ister.org/code/article/de/php45bench.xhtml indicate that PHP5 is slower than PHP4, but in the note at the end there is some evidence that PHP5.1 will be significantly faster than PHP4 when it comes to objects and classes (which is what people who do more with PHP will be using). AllOLLi Backup? Backup? ...I knew I forgot something! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Pierre schrieb: This argument is irrelevant. You only hide the possible lack of scalability behind hardware improvements. A lack of scalability will only occur if the Unicode features create a more than linear performance drop which I suppose won't happen. Even if it becomes three times slower this is NO problem to think about when deciding for or against a side-by-side unicode/non-unicode environment since this is very well scalable. AllOLLi According to my calculations the problem doesn't exist. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Oliver Grätz wrote: http://www.ister.org/code/article/de/php45bench.xhtml indicate that PHP5 is slower than PHP4, but in the note at the end there is some evidence that PHP5.1 will be significantly faster than PHP4 when it comes to objects and classes (which is what people who do more with PHP will be using). Tests conducted using real PHP applications such as Gallery,FUDforum,phpMyAdmin show different results. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Thu, 13 Oct 2005, Oliver Grätz wrote: And people will do more with PHP ultimately making the MHz boost irrelevant. Despite tremendous increases in hardware performance, the software we run seems to run slower and slower. Which doesn't stop them from moving from PHP to Ruby (which I suppose is slower than PHP will ever be). And that they're perfectly free to do. I even encourage them to do so if it provides what they need now instead of waiting what we'll break next. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Jani Taskinen schrieb: [...] instead of waiting what we'll break next. *ROTFL* You seem to develop a healthy fatalism ;-) Bier? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Thu, 13 Oct 2005 21:02:09 +0200 [EMAIL PROTECTED] (Oliver Grätz) wrote: Pierre schrieb: This argument is irrelevant. You only hide the possible lack of scalability behind hardware improvements. A lack of scalability will only occur if the Unicode features create a more than linear performance drop which I suppose won't happen. Even if it becomes three times slower this is NO problem to think about when deciding for or against a side-by-side unicode/non-unicode environment since this is very well scalable. You miss my point. Saying that in one year hardware will run a few Mhz faster is plain stupid. You only delay the point of failure. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Thu, 13 Oct 2005, Oliver Grätz wrote: Jani Taskinen schrieb: [...] instead of waiting what we'll break next. *ROTFL* You seem to develop a healthy fatalism ;-) I'm just realistic. I _KNOW_ we're gonna break stuff. Intentionally, accidently and accidently. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals [EMAIL PROTECTED] (Adam Maccabee Trachtenberg) wrote: We seem to be under the impression that the Unicode speed penalty will be so harsh that a Unicode-only PHP 6 will be too slow for use. However, we don't know that for sure. Yes, it will be slower, when you look at the whole request cycle, it may not matter. I agree - the speed penalty comparsion seems mostly related to php scripts that does nothing else than handling strings. I recall the old discussions (echo vs print vs ?...? ) using similar benchmarks. It is true when you compare the specific functions/language constructs the relative difference in speed is apparent. But compared to a bunch of other functions that you'll usually use (database connections, file access, data sorting, etc.) I imagine that the speed penalty is simply marginal. Just my 0.02 \x20B1. -- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 7 Oct 2005, Derick Rethans wrote: On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? I got to agree with Derick. I certainly understand that speed is important, but people somehow manage to develop Web sites in Java, C#, and Perl, and all those languages are Unicode only. We seem to be under the impression that the Unicode speed penalty will be so harsh that a Unicode-only PHP 6 will be too slow for use. However, we don't know that for sure. Yes, it will be slower, when you look at the whole request cycle, it may not matter. Therefore, all the extra work we're doing today seems to be premature optimization (a.k.a. the root of all evil) that only adds to code complexity and delays PHP 6. We'd be better off building PHP 6 as Unicode-only and spending the extra time that we're currently using on the non-Unicode mode tuning PHP 6 the best we can. If we somehow fail to get it fast enough for a certain subset of users, and those users cannot afford to buy better machines, then and only then should we figure out how solve the problem of making PHP 6 support a non-Unicode mode. -adam -- [EMAIL PROTECTED] | http://www.trachtenberg.com author of o'reilly's upgrading to php 5 and php cookbook avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Thu, 6 Oct 2005, Andrei Zmievski wrote: On Oct 6, 2005, at 10:56 AM, Derick Rethans wrote: I think I would prefer an IS_UNICODE/unicode=on only PHP. This would mean that: - no duplicate functionality for tons of functions that will make maintaining the thing very hard This is true. - a cleaner (and a bit faster) Unicode implementation This is true too. - we have a bit less BC. A bit less? I'd say it would break BC in a major way. People who want to upgrade to PHP 6 would need to rewrite a lot of their scripts. Can you please specify which things you think that will break? I've gave it some thoughts but couldn't really think of anything serious... This is something I find quite not acceptable, and we need to figure out a way on how to optimize this - for substr the penalty is probably what we are using an iterator and not a direct memcpy (because of surrogates), I am not so sure about the others. We can try switching to _UNSAFE versions of the iterator macros - they assume well-formed UTF-16, so they will be somewhat faster. That's worth a try - I'll put that on my todo list somewhere. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Andrei Zmievski wrote: - we have a bit less BC. A bit less? I'd say it would break BC in a major way. People who want to upgrade to PHP 6 would need to rewrite a lot of their scripts. I think most large applications will be in this boat anyway, we may as well do it properly once, so we don't end up hacks on top of hacks just for the sake of BC. We can try switching to _UNSAFE versions of the iterator macros - they assume well-formed UTF-16, so they will be somewhat faster. We definitely need to look at that since if upgrading to 6.0 means a 3x slower operation very few people will even consider upgrading. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Ilia Alshanetsky wrote: Andrei Zmievski wrote: - we have a bit less BC. A bit less? I'd say it would break BC in a major way. People who want to upgrade to PHP 6 would need to rewrite a lot of their scripts. I think most large applications will be in this boat anyway, we may as well do it properly once, so we don't end up hacks on top of hacks just for the sake of BC. We can try switching to _UNSAFE versions of the iterator macros - they assume well-formed UTF-16, so they will be somewhat faster. We definitely need to look at that since if upgrading to 6.0 means a 3x slower operation very few people will even consider upgrading. Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: We definitely need to look at that since if upgrading to 6.0 means a 3x slower operation very few people will even consider upgrading. Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Derick Rethans wrote: On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: We definitely need to look at that since if upgrading to 6.0 means a 3x slower operation very few people will even consider upgrading. Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? The don't upgrade argument doesn't work. Unless we commit to having two major versions forever where we will add new features. That is a possibility as well of course. Have 2 trees. Unicode-PHP and non-Unicode-PHP and everything that is not Unicode-related will need to be committed to both. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Oct 7, 2005, at 5:05 PM, Derick Rethans wrote: On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? The don't upgrade argument doesn't work. Unless we commit to having two major versions forever where we will add new features. That is a possibility as well of course. Have 2 trees. Unicode-PHP and non-Unicode-PHP and everything that is not Unicode-related will need to be committed to both. yeah, and if that allows us to cleanup PHP 6 for real, then I am not even sure if that is such a bad solution. Ofcourse, the new cool features would go to PHP 6 only, but that's now the same wih 4.4 and 5.1 too anyway. But I don't want to jump too quickly to conclusions about the UNicode speed and BC breakage. All I tested is raw string functions and there is no way that the whole application slows down as much as we saw in the few benchmarks that I run. Besides that, we can probably optimize the string functions somewhat anyway. I'd like to see the speed decrease for real applications too. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. So, you are saying that something like the namespace patch would be added between 5.1.2 and 5.1.3, for example? That doesn't make much sense to me. True, but doing it between 5.1.1 and 5.2.0 would work. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Oct 7, 2005, at 5:41 PM, Rasmus Lerdorf wrote: Ilia Alshanetsky wrote: George Schlossnagle wrote: What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. So, you are saying that something like the namespace patch would be added between 5.1.2 and 5.1.3, for example? That doesn't make much sense to me. Perhaps we need a separate version fork for the unicode support. I'm thinking one of those nifty unicode glyphs. It could be called 'the language formerly known as PHP'. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Derick Rethans wrote: On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. So, you are saying that something like the namespace patch would be added between 5.1.2 and 5.1.3, for example? That doesn't make much sense to me. True, but doing it between 5.1.1 and 5.2.0 would work. Right, so effectively the 5.x and 6.x trees would mimic each other. Even major versions = unicode, odd version = non-unicode. I suppose it is an approach, but I think it is a confusing one. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
George Schlossnagle wrote: Perhaps we need a separate version fork for the unicode support. I'm thinking one of those nifty unicode glyphs. It could be called 'the language formerly known as PHP'. The Phillipine currency is called PHP. Do they perhaps have a currency symbol? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote: The don't upgrade argument doesn't work. Unless we commit to having two major versions forever where we will add new features. That is a possibility as well of course. Have 2 trees. Unicode-PHP and non-Unicode-PHP and everything that is not Unicode-related will need to be committed to both. I think this would lead to PHP 6.2 with two different sets of functionality (Joe writes some super-string-manipulating thing for PHP 6.2, never find the time to port it to 6.2-unicode, and now no one else has time to do it either so we release one with the function, one without yet they are both 6.2). While I understand the argument that PHP itself will be slower with Unicode support, and there isn't much we can do about that (we're just doing a heck of a lot more work across the board), I think the best option is to have PHP 6 be completely Unicode. It will break applications, but they can be ported. It will mean PHP is going to be slower, but other languages have found ways to make up for that speed decrease in other places and I am sure we could learn from looking at them for answers to our problem. Cheers, John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Hello John, Friday, October 7, 2005, 11:47:14 PM, you wrote: On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote: The don't upgrade argument doesn't work. Unless we commit to having two major versions forever where we will add new features. That is a possibility as well of course. Have 2 trees. Unicode-PHP and non-Unicode-PHP and everything that is not Unicode-related will need to be committed to both. I think this would lead to PHP 6.2 with two different sets of functionality (Joe writes some super-string-manipulating thing for PHP 6.2, never find the time to port it to 6.2-unicode, and now no one else has time to do it either so we release one with the function, one without yet they are both 6.2). While I understand the argument that PHP itself will be slower with Unicode support, and there isn't much we can do about that (we're just doing a heck of a lot more work across the board), I think the best option is to have PHP 6 be completely Unicode. It will break applications, but they can be ported. It will mean PHP is going to be slower, but other languages have found ways to make up for that speed decrease in other places and I am sure we could learn from looking at them for answers to our problem. For instance PHP 6 could undergo a design face for some clearing which should imho includecase-sensitivity every where and ups, why is PHP 6 suddenly faster? We could also add a mode that disalloas dynamic class rewriting which is very clever once we have the build in apc or which ever bytecode compiler we chosse and ups! no it is even much faster when using objects. But to me the best thing would be to finally haver a plan. A real plan we stick to. And then outline how long we plan to support 5.x series. Because if we do so we can finally take us some time and change a few things in 6. But maybe some companies like it more to get 6 out asap and have little BC issues every now and then. Those companies with their private code - they don't have a real problem with that. It is the majority of small sites. People that want new features every now and then. And then it is a problem because the majotity of servers come with exactly one PHP version installed. Perhaps it is a good idea to suggest to have PHP 4.*, PHP 5.* and PHP 6.* installed in parallel. Because only if we suggest so that might happen. And if it happens there is no such thing as BC. But well is any body still reading or caring for what i write? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Fri, 7 Oct 2005, Ilia Alshanetsky wrote: George Schlossnagle wrote: What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. 5.1, 5.2, 5.3..where was it said that 5.1 has to stop at 5.1 ? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Rasmus Lerdorf wrote: George Schlossnagle wrote: Perhaps we need a separate version fork for the unicode support. I'm thinking one of those nifty unicode glyphs. It could be called 'the language formerly known as PHP'. The Phillipine currency is called PHP. Do they perhaps have a currency symbol? -Rasmus http://www.fileformat.info/info/unicode/char/20b1/index.htm An uppercase P with two horizontal bars through the top :-) Cheers -- David Robley Shotgun wedding: a case of wife or death. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
Hello Derick, Thursday, October 6, 2005, 7:56:34 PM, you wrote: Hello! I am thinking that we're doing something with the unicode implementation and that's that we're now getting duplicate implementations of quite some things: functions, internal functions, hash implementations, two ways for storing identifiers... only because we need to support both IS_STRING and IS_UNICODE and unicode=off mode. I think I would prefer an IS_UNICODE/unicode=on only PHP. +infinity (...) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
