Philip, I assumed what is supposed to be documented is not just a boolean
switch: "this is unicode compatible" / "this is not yet unicode
compatible", but there are behaviour changes, special options, or anything
(I am not actually following PHP 6 development). In case it is just a
boolean switch, then indeed there is no point in documenting it. It seems
Andrei tries to push the point across that we are not talking about
boolean switches.
Gabor
On Wed, 19 Jul 2006, Philip Olson wrote:
I'm unsure if I follow what you mean here Gabor, please clarify.
If we do this soon then later we'll undo it all because when PHP 6.0.0 is
released every [appropriate] function will be unicode compatible so
repeating this thousands of times throughout the manual won't be useful. The
appropriate place to document "the progress" of unicode support for pre PHP 6
should not be in all these manual pages as we do not document alpha/beta
releases. If for some reason a function is missed and support is given in,
for example, PHP 6.0.1 then we will mention this in the CHANGELOG for said
function. But as it stands, everyone is expected to assume unicode support
everywhere as that's what PHP 6 is all about.
So, it feels right to document unicode compatibility in a few places like the
language reference, features, migration sections, related extension docs
(mbstring/iconv/...)... but not per function. In the end people will see the
light but not be blinded by it ;-) Also it might be appropriate to document
it for each extensions reference.xml as it will be informative and also help
promote this new feature.
Regards,
Philip
