Andi Gutmans wrote:
Anyway, as I suggested, let's do more homework. We started and it wasn't a
pretty sight. But still lots to do. There seem to be enough passionate people
on this list to actually port 3-4 apps over and give us some more input on the
answers we really need.
I have kept out of this debate - lack of time - and while I'm probably one of
the '95%' I *DO* understand that not having unicode available is MORE of a
headache so I need to be more pro-active in using it.
How much work do people think *IS* involved in porting a large application
over to PHP6? Reading between the lines it looks like we are talking file
conversion to UTF-16 + what? What is currently a show stopper to simply
running a PHP5 application? I used to keep a PHP6 setup here but that had to
go with all the crap involved in the different versions of PHP5.? so I haven't
had a PHP6 copy running for some time :( - but the bitweaver framework does
allow easy code management so I would be prepared to spend time at least
starting to have a look!
No I'm absolutely not OK with removing this switch and as we currently
did most of the implementation for it and are maintaining it I see no
reason to remove it. 95% of our users couldn't care less about native
Unicode support except for the performance hit they'd take due to the
slower functions and increased memory usage. For most of them they gain
nothing and only loose.
( Top posting sucks ;) )
I suppose this is the difference between native UTF-8 and UTF-16? If you only
use the 127 character ascii set then there is no difference between UTF-8 and
ASCII? So I assume that the alternative half way house is currently being
discussed and everything will be UTF-16 and 16 bit characters? Given that
there are now two branches to MOST operating systems (32 bit and 64 bit) I see
no reason that there should not be two builds of PHP6 but to be honest I am
probably in the native unicode camp. Keep PHP5.x for 8bit character sets, and
develop PHP6 as 32bit ready for the processors that are already available to
use it. It will be another 10 years before PHP5 reaches a point were it may
want to die by which time who knows how much memory and how many processor
cores we will have in our PDA's :)
The one thing to avoid is the situation that happened with PHP4, where many of
the good reasons for changing were simply back ported? Either we see PHP6 as a
natural progression to PHP5, nothing gets 'back ported', and PHP6 runs PHP5
applications out of the box, or PHP6 requires a 'conversion package' to
transfer PHP5 applications and provides a clean unicode environment. In the
first case we need the switch - in the second *I* would be looking for 32 bit
character clean code. A half way house of UTF-16 way may as well have the
switch, since all the code to manage multiple 'byte' characters is still
messing up the code base - and we start looking at PHP7 :(
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
