Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)

At 17:46 24/08/2005, Rasmus Lerdorf wrote:

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.

Not quite; As far as binary compatibility we agree, there's no way we'll retain binary compatibility, and API versioning is the built-in method to notify users about that. But, you mentioned (and I agree) that it would be annoying for things to stop working if unicode is turned on. While it's impossible to truly prevent that from happening (we can't force everybody to maintain unicode-compatible code everywhere), we can give extension authors a way to denote whether their extensions are compatible with unicode or not. If not - these extensions will become inaccessible when unicode semantics is enabled.

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.

Why? A great deal of users will be running with unicode semantics turned off, and I don't see a good reason to break source compatibility for them. For example, if Foo Inc. wrote a module for PHP 4, and they want to migrate to PHP 6 - it should be a simple recompile. It's OK if we barf when they turn unicode_sematics off, but not if they don't. Zeev