Re: Re: [php-icu] Graphemes and unicode vs intl extension

From: Date: Sat, 22 Mar 2008 21:09:19 +0000
Subject: Re: Re: [php-icu] Graphemes and unicode vs intl extension
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-36337@lists.php.net to get a copy of this message
Hello Pierre, Saturday, March 22, 2008, 10:01:31 PM, you wrote: > On Sat, Mar 22, 2008 at 6:57 PM, Derick Rethans <derick@php.net> wrote: >> On Fri, 21 Mar 2008, Pierre Joye wrote: >> >> > On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans <derick@php.net> wrote: >> > > On Fri, 21 Mar 2008, Stanislav Malyshev wrote: >> > > >> > > > > You can't actually use the class name "DateFormatter" >> > > > > when you want >> > > > > pecl/intl to be in core. "Date" is the prefix for the >> > > > > already existing Date >> > > > > extension. >> > > > >> > > > I think we still can name it DateFormatter, especially if we plan (and we >> > > > do, >> > > > as I understand) to merge DateFormatter functions with ext/date in PHP 6, >> > > > and >> > > > we don't have any conflict now and we do not have any plans to have >> > > > DateFormatter in ext/date (correct me if I'm wrong here). >> > > >> > > You're wrong. We can rename it later *if* it gets merged into ext/date, >> > > but you can't simply use a classname with a prefix that conflicts with >> > > something else. Merging it would most likely change API anyway. >> > >> > I rather prefer to have this class (and related) within the ext/date >> > extensions. It is the only way to have a consistent and working >> > date/time API in php. Date/time formatting is part of this API. >> >> I've mentioned that from the beginning (and started experimenting a bit >> with it already as date_format_locale()), but apparently that's not the >> "correct" way. > I don't want to start yet another rant but there is two things that > rather annoy me here: > 1. I never heard of this mailing list, my question about its origin > and whether is public or not has been simply ignored > 2. It seems that there is no way to change minds of some employee(s) > of some company(ies) > The 2. is annoying and we have ways to force a choice, that does not > worry me too much. But 1. is yet another step in the wrong direction. In case you were speaking of php-icu@lists.zend.com, then I have to agree as that one should not be used to decide about anything in PHP. There is an official list php-i18n@lists.php.net out there that should serve for decisions on PHP's internationalization. Best regards, Marcus

« previous php.internals (#36337) next »