Re: Re: [php-icu] Graphemes and unicode vs intl extension
| From: | Marcus Boerger | 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