I was thinking a bit more about this yesterday. Even if I'd agree with this discussion (which I don't at this point in time) I think it is being had far too early. We currently have a very big problem with ability to upgrade to PHP 6 and making decisions without people actually getting their feet wet and seeing what the issues are is not a good idea. Purist decisions tend to fail when they meet the real world.
What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. It's something we are willing to spend time on and as I mentioned already started to do but it would really require a larger amount of volunteers to pick various apps and do it. This kind of information would be far more valuable to the project at this point than a prolonged thread about a piece of software which isn't finish (and would also give more information for a discussion like the one we've been having). No one really knows how good/bad of a situation we are at right now. I know from my end it doesn't look great yet. Andi > -----Original Message----- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Monday, July 09, 2007 7:39 PM > To: Antony Dovgal; Andrei Zmievski > Cc: Stas Malyshev; internals@lists.php.net > Subject: RE: [PHP-DEV] What is the use of "unicode.semantics" > in PHP 6? > > The large amount of the dual IS_UNICODE/IS_STRING will need > to stay in the code base anyway as we will be supporting > binary strings in PHP 6. > So it's not accurate that all these maintance issues will be > resolved by not supporting unicode_semantics=off. > > I believe unlike what Andrei said, for a large community of > ours (probably the majority) default unicode_semantics=on > will not be of interest (we don't live in a purists world). > Many won't want to run it because it's going to be > significantly slower and will be harder for them to work > with. This community will be best served to be able to run in > native 8bit mode and having some Unicode functionality > available if/when needed. Having dual mode in PHP 6 is not > the same as forking two code bases. There is still like > namespaces automatically reach both audiences. > > If we're talking from a pure "what is most useful to the > majority of our users" I'd actually argue that explicit > Unicode strings would be the most convenient, i.e. instead of > doing b"8bitstring" you'd do U"unicodestring". Other > languages do the same and there are reasons for that. As > we've decided on a more aggressive (and risky) approach, I > think having this dual mode is extremely important. It will > also make the upgrade path easier. > > Btw, I don't know how many of you have actually tried to port > PHP 5 apps to PHP 6 but it's quite a disaster. We made some > fixes in the past 2-3 weeks and its getting better but it > still requires a lot of work. If we don't make this easy then > this is all not worth too much. > > This project has never been a purists project which is why > it's been so successful, let's not start now... > > Andi > > -- > 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
