Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36794
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.131 cause and error)
Message-ID: <47F5DC3D.6090302@lsces.co.uk>
Date: Fri, 04 Apr 2008 08:43:57 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <47F463F0.4030407@zend.com> <47F47360.8040606@lsces.co.uk> <47F560E4.7060609@zend.com>
In-Reply-To: <47F560E4.7060609@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] intl naming
From: lester@lsces.co.uk (Lester Caine)

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