I see I may not have been clear in my previous email. Indeed as Stas mentioned I agree we should not have a php.ini switch, i.e. unicode.semantics goes away.
At the same time I propose: a) We invest considerable energy in figuring out and documenting the migration path. b) We build automated migration scripts when possible (like we did in PHP/FI 2 -> PHP 3 ) to make the migration easier. c) We keep an open mind regarding some areas which could make it easier to adopt especially when the net benefits only affect a smaller audience or audiences which already today are used to working harder with various languages (e.g. fgets() returning IS_STRING by default, "foo" produces IS_STRING, and u"foo" produces IS_UNICODE, ...). These are just examples and I think reality will depend on (a). I think the current core development team will definitely need help from all the lurkers on this list. There seems to be plenty of energy for long email threads so let's convert that energy into some productive contributions around function upgrades and migration path :) I don't think this affects PHP 5.3 (http://wiki.pooteeweet.org/PhP53VoteResult) which I believe we're making good progress on. It allows us to get some of those features out earlier including things like namespaces which the various framework communities badly need. It will also allow many users who need ICU functionality to start using APIs which will be forward compatible with PHP 6. Andi > -----Original Message----- > From: Steph Fox [mailto:[EMAIL PROTECTED] > Sent: Monday, January 21, 2008 5:30 PM > To: Stas Malyshev > Cc: Andi Gutmans; Antony Dovgal; internals@lists.php.net > Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch > ASAP > > > I think the idea was "no php.ini switch, but the question what "foo" > > should produce - IS_UNICODE or IS_STRING is still open for > consideration". > > "foo" alone should produce IS_STRING. The real question IMHO is how far > back > do you backport tolerance for a unicode cast. > > - Steph
