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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
