Stanislav Malyshev wrote:
Hi!
I suppose the main question here is the simple one.
Will PHP6 be integrally - unicode?
Sure, it will :)
run anything else - use PHP5 for an 'ascii' based version ) then why
are we discussing separating out functions which are part of that core.
Because we need them much sooner than PHP 6 would be released. We need
them yesterday.
THAT I agree with - BUT WHAT IS STOPPING PHP6 being the solution. I can't see
any reason that time is being wasted on yet another PHP5.X when that same
effort could be directed to getting at least a stable beta of PHP6 out the door?
The core objects should properly handle unicode, so why have DUPLICATE
functions such as Date and DateFormatter at all? Number and possibly
We don't duplicate them, we add them.
intl itself is a duplication or rather creation of additional functions which
SHOULD simply be provided by the core functions.
MessageFormatter simply duplicates and complicates a simple display of a
message with embedded variables. If I ask for to output a string with
variables in using a different locale then the DATE variables should simple
display the correct format for that locale. I should not have to go through
all the code and re-write the variables in some complex format so another
package can then do the same job that the core system IS ALREADY DOING?
Collator is already required to process strtoupper and strtolower, so why
should we need to decide if we can use them or we need to create a new object
and get that to do the job.
PLEASE - what is stopping PHP6 becoming a platform that we can start working
with today?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
