Zeev Suraski 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.
Doesn't this go against what you just said about breaking things on purpose? I don't think we need anything beyond the API versioning here. We should be able to deal with extensions that correctly use zend_parse_parameters for their argument handling. But for extensions that don't, I think there is no way to maintain source compatibility and I think it may be an idea to stop these from even building. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
