Stanislav Malyshev wrote:
Hi!
I meant to duplicate the code from ext/date (where it belongs) in
pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is
to provide the DateFormatter feature to php 5.2 users.
Great, right now 5.2 users can use intl extension from pecl, including
Hi!
I meant to duplicate the code from ext/date (where it belongs) in
pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is
to provide the DateFormatter feature to php 5.2 users.
Great, right now 5.2 users can use intl extension from pecl, including
DateFormatter.
As Derick
On Wed, Mar 26, 2008 at 9:38 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
> > This feature can then be optional in ext/date. That should not be an
> > issue for those not willing to use a reliable date formatting system
> > as they are certainly not interested in intl either.
>
>
Hi!
This feature can then be optional in ext/date. That should not be an
issue for those not willing to use a reliable date formatting system
as they are certainly not interested in intl either.
I think making it optional in ext/date would be harder. On top of that,
optional functions in exis
Hi,
On Wed, Mar 26, 2008 at 9:02 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
> > As intl will requires it, why is it unacceptable?
>
> intl is specialized extension for people dealing with global
> environments. It will be enabled only by people that really need it.
> ext/date
Hi!
As intl will requires it, why is it unacceptable?
intl is specialized extension for people dealing with global
environments. It will be enabled only by people that really need it.
ext/date is much more general-purpose function, used by thousands of
applications that don't care at all ab
On Wed, Mar 26, 2008 at 8:29 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I am not so sure. I see (in the feb-04 sources) just collator,
> > formatter, locale, msgformat and normalizer - and dateformatter that
> > should be integrated into the Date extension to avoid issues and
> > conf
I am not so sure. I see (in the feb-04 sources) just collator,
formatter, locale, msgformat and normalizer - and dateformatter that
should be integrated into the Date extension to avoid issues and
confusion.
I'm all for integrating it in PHP 6, however I do not see how it is
possible to do it
and there is no chance to wait?
To wait for? 5.2 is out there, and there are a lot of people needing
intl support. We are working on this project for almost a year now, so
we want to make a release. Of course, 1.0 is not the end of story, and
we are very much intending to work further, but
Hello Stanislav,
and there is no chance to wait?
Friday, March 21, 2008, 7:25:44 PM, you wrote:
>> Did you experiemnt with namespaces?
> No, the reason is ext/intl should work with 5.2.
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8
Did you experiemnt with namespaces?
No, the reason is ext/intl should work with 5.2.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Hello Stanislav,
Friday, March 21, 2008, 6:50:53 PM, you wrote:
>> In this case, all of the classes in pecl/intl should start with Intl.
> IntlMessageFormatter is a pretty sucky name... But maybe if we don't
> have another bright idea I guess that'd be the way to go. Pity we didn't
> figure i
Thanks Stas. Yes, it was because the INTL extension included unrelated modules,
that we opted out of the extension naming.
Besides the formatters we have graphemes and unicode normalization functions.
I don't see that we have an actual collision here, so I would be inclined to
keep things as the
In this case, all of the classes in pecl/intl should start with Intl.
IntlMessageFormatter is a pretty sucky name... But maybe if we don't
have another bright idea I guess that'd be the way to go. Pity we didn't
figure it out earlier in the loop, but I'm guessing it should not be too
hard to
14 matches
Mail list logo
