Hello Zeev, Wednesday, August 24, 2005, 4:41:25 PM, you wrote:
> At 17:37 24/08/2005, Rasmus Lerdorf wrote: >>Steph wrote: >> > Hi Rasmus, >> > >> > >> >>Steph wrote: >> >> >> >>>If there's the capability to run PHP 6 without Unicode support, surely >> >>>there's no reason for extensions to lose back compatability when they're >> >>>updated...? >> >> >> >>That's going to be tough. They will definitely lose binary >> >>compatibility because all sorts of internal structures are changing >> >>which a runtime switch can't do anything about. We may be able to keep >> >>compatibility at the source level, but having extensions that fall over >> >>when you turn on unicode semantics would be a real pain. It might be a >> >>feature to break them and have a nice FAQ on what needs to be done to >> >>upgrade the extension to support Unicode. >> > >> > >> > Ouf - you're effectively saying that Unicode support will need to be >> enabled >> > via INI directives on a per-extension basis? Or that there will need to be >> > two versions of every PHP extension? >> >>Not at all. But it would be nice if the extension did something >>intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't >>just exist when unicode semantics are turned on either. So it actually >>doesn't matter if that switch is on or not, extensions should handle >>Unicode strings. > Maybe we can give extensions a way to indicate that they're Unicode > compatible, and assume they're not if they don't. Non-compatible > extensions will not be loaded and produce an error. What is this, a try to incorporate a way of creating BC issue on purpose before releasing and without the ability to fix them later? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
