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

Reply via email to