bugs.php.net & php 6

The development of the unicode-as-default-charset should really be
done
within the next release coming after 5.4
I heared somewhere that it's nearly done ...
I would have happily seen it in 5.4 but as this release is late right
now
we have to wait ;)

I was off on medical leave for awhile, but last I heard, the one (1)
guy who cared enough to work hard-core on a Unicode PHP realized just
how terribly difficult it was, and just how many irreconcilable issues
it raised, and he stopped working on it.

Nobody else has taken up the banner, and PHP 6 trunk was moth-balled
and started over, or so I heard...

That sums up, even over-simplifies, a whole mess of threads,
discussions at conferences, and IRC discussion in a couple
sentences... I apologize to all for the over-simplification, and
possibly outright errors.

While I understand the allure of writing code in one's native
language, and the ease of having one's native language supported out
of the box in the string built-in type...

There are mechanisms available in PHP now, which are more cumbersome,
but they work without the very complex issues alluded to in paragraph
1..

Other languages may have this feature, but they were included from the
beginning. Grafting them on to PHP at this point was attempted, and,
as far as I know, failed. It was an ambitious attempt, and the issues
could not have easily been foreseen, so it's probably very
disheartening to have failed just short of the goal line.

That's the way the ball bounces sometimes.

Again, please forgive me if I have completely failed to catch
something here, especially as I'm just getting back into the flow of
things.

some more info
http://lwn.net/Articles/379909/
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
so yeah, the full unicode support happened to be too big to undertake (and
in retrospective it seems that the UTF-8 would have been a wiser choice
instead of UTF-16), and having to upgrade all of the extensions was also a
grand task.

so the unicode development got halted, which in turn made the whole php6
project into a death march.
after some marching 5.3 got branched from 5.2, the stuff ready in php 6 got
backported and released, then people realized that it is nowhere else to
go, moved trunk to branches/FIRST_UNICODE_IMPLEMENTATION/, and rebranched
trunk from 5.3, which in turn get turned into 5.4.

ps: and it was a big messy discussion about the namespace operator.
ps2: feel free to correct/extend my info. ^^

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

John Crenshaw wrote:

Wait, is the default going to be "Unicode" (wide, always 2 bytes per char, I.E. more memory consumption) or "UTF-8" (1 byte for the first 127, more bytes for wider text, mostly unchanged memory consumption)? I thought it was originally a conversion to Unicode, but that was scrapped? Can someone clarify?

I seem to recall that the original plan was along the lines of windows wide
string? But it was the fact that unicode is wider then 16 bit that this was
simply wrong? Trying to shoehorn things into the wrong structure was just not
working and making the job more difficult?

Keeping things simple really requires 4 bytes per character, even if one of
those is never used, but it does make sense when manipulating strings? However
most of the time UTF8 works happily and only becomes a problem when a multibyte
character gets cropped because the processing does not know about it?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php