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
On Sun, 23 Mar 2008, Tex Texin wrote:
Pierre, Marcus, et al.
1) The project started a year or so ago. A few of us from different
companies had a strong need to see that PHP had international
collation, formats, normalization, grapheme support, and other
functions in a time frame nearer
On Sun, 23 Mar 2008, Steph Fox wrote:
Few people want this extension to be moved to core, which means: every
decision about this extension is deciding anything about PHP.
Those 'few people' were actually in the majority when it was put to the vote.
Yes development could and should've been
On Sun, 23 Mar 2008, Stanislav Malyshev wrote:
Noone is arguing about the usefulness of the extension.
We are arguing about how the maintainers of the extension are about to
abandon it once it reaches -stable and the fact it doesn't even try to
Hannes, wtf you are talking about? Nobody
On Sun, 23 Mar 2008, Lester Caine wrote:
Derick Rethans wrote:
On Fri, 21 Mar 2008, Pierre Joye wrote:
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
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
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
confusion.
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
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 is much
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
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.
I think
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
Dammit, I sat on this record and I broke it..
:)
-Andrei
Pierre Joye wrote:
By the way, when was this list created? Why discussions about the
development of this upcoming core extension are not public and under
php.net? I don't think it is a good thing and I dislike this way of
working.
On Mon, Mar 24, 2008 at 6:08 PM, Andrei Zmievski [EMAIL PROTECTED] wrote:
Precisely. It was never a secret, despite someone's paranoidal
proclaiments..
It was not a secret per se and someone was not paranoid, please stay
polite and respectful, thank you.
But, there is a huge difference
Derick Rethans wrote:
On Fri, 21 Mar 2008, Pierre Joye wrote:
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] 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
Boerger [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 22, 2008 2:09 PM
To: Pierre Joye
Cc: Derick Rethans; Stanislav Malyshev; sf.chen; Tex Texin; [EMAIL PROTECTED];
Ed Batutis; Hong,Weilin; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hi Tex
On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote:
Pierre, Marcus, et al.
1) The project started a year or so ago.
So for a whole year none of you (not even the Zend employees that
should know better) thought that there maight be a coding standard
that you should
Hello Tex,
Sunday, March 23, 2008, 10:03:15 AM, you wrote:
[...]
Several of us working on this project don't know PHP internals.
This sounds extremely unprofessional and ignorant. And especially shows
that you do not at all care for PHP. If I work with something I usually try
to get an
Hello Hannes,
Sunday, March 23, 2008, 12:43:20 PM, you wrote:
Hi Tex
On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote:
Pierre, Marcus, et al.
1) The project started a year or so ago.
So for a whole year none of you (not even the Zend employees that
should know
Hey Hannes,
Few people want this extension to be moved to core, which means: every
decision about this extension is deciding anything about PHP.
Those 'few people' were actually in the majority when it was put to the
vote. Yes development could and should've been made public all along, but
On Sun, Mar 23, 2008 at 2:37 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hey Hannes,
Few people want this extension to be moved to core, which means: every
decision about this extension is deciding anything about PHP.
Those 'few people' were actually in the majority when it was put to the
Texin
Cc: Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hello Tex,
Sunday, March 23, 2008, 10:03:15 AM, you wrote:
[...]
Several of us working on this project don't know PHP internals.
This sounds extremely
AM
To: Tex Texin
Cc: Marcus Boerger; Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hi Tex
On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote:
Pierre, Marcus, et al.
1) The project
So for a whole year none of you (not even the Zend employees that
should know better) thought that there maight be a coding standard
that you should follow?
We followed the coding standard. Coding standard never says there should
be single prefix per extension and this prefix should be
Noone is arguing about the usefulness of the extension.
We are arguing about how the maintainers of the extension are about to
abandon it once it reaches -stable and the fact it doesn't even try to
Hannes, wtf you are talking about? Nobody even thinks about abandoning it.
To make matter worse
On Sun, Mar 23, 2008 at 8:30 PM, Tex Texin [EMAIL PROTECTED] wrote:
The first thing we did was look at the coding standard.
OK. Well done then.
I guess I was just very unlucky picking locale/locale_methods.c to view then.
Stas explained the reason we chose the naming we did.
Which is great.
Those 'few people' were actually in the majority when it was put to the
vote. Yes development could and should've been made public all along,
but the fact remains that intl offers damn useful functionality.
It was and is public. For heaven's sake, APIs are in the manual! Not
counting the
-Original Message-
From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 1:31 PM
To: Tex Texin
Cc: Marcus Boerger; Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun
On Fri, 21 Mar 2008, Pierre Joye wrote:
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] 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
On Sat, Mar 22, 2008 at 6:57 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Fri, 21 Mar 2008, Pierre Joye wrote:
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Fri, 21 Mar 2008, Stanislav Malyshev wrote:
You can't actually use the class name
Hello Pierre,
Saturday, March 22, 2008, 10:01:31 PM, you wrote:
On Sat, Mar 22, 2008 at 6:57 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Fri, 21 Mar 2008, Pierre Joye wrote:
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Fri, 21 Mar 2008, Stanislav
Hi Marcus,
On Sat, Mar 22, 2008 at 10:09 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
In case you were speaking of [EMAIL PROTECTED], then I have to agree
as that one should not be used to decide about anything in PHP. There is an
official list [EMAIL PROTECTED] out there
change today.
tex
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:35 AM
To: Stanislav Malyshev
Cc: sf.chen; Tex Texin; [EMAIL PROTECTED]; 'Ed Batutis'; 'Hong,Weilin'; PHP
Developers Mailing List
Subject: [PHP-DEV] Re: [php-icu] Graphemes
On Fri, Mar 21, 2008 at 6:01 PM, Tex Texin [EMAIL PROTECTED] wrote:
I admit to being unclear on why DateFormatter conflicts with Date. I'll have
to read the manuals later. Seems rather limiting if all names beginning with
Date are now verboten. That said:
A) Derick, Shifu, Can you (or
On Fri, 21 Mar 2008, Tex Texin wrote:
I admit to being unclear on why DateFormatter conflicts with Date.
I'll have to read the manuals later. Seems rather limiting if all
names beginning with Date are now verboten. That said:
A) Derick, Shifu, Can you (or anyone) demonstrate the name
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
All functions in pecl/intl should therefore be named intl_foobar() and
classes intlFooBar in theory.
Well, intl module as I mentioned is a bit different - it has functional
parts which could be in fact separate extensions, but for practical
reasons aren't. So leaving aside the collision with
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] 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
as they are.
tex
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 10:51 AM
To: Derick Rethans
Cc: Tex Texin; [EMAIL PROTECTED]; PHP Developers Mailing List
Subject: Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs
intl
Hi!
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.
That'd be kind of hard to do because it uses ICU infrastructure, which
would create
Hello Stanislav,
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
marcus
Friday, March 21, 2008, 6:52:52 PM, you wrote:
All functions in pecl/intl should therefore be
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 it
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:
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
Well, in date manual as I can see there are 2 prefixes: date_ and
timezone_. And in SPL there are non-prefixed iterators,
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-8829
Hello Stanislav,
Friday, March 21, 2008, 7:31:59 PM, you wrote:
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
Well, in date manual as I can see there are 2 prefixes:
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
Hi,
Stanislav Malyshev wrote:
All functions in pecl/intl should therefore be named intl_foobar()
and classes intlFooBar in theory.
Well, intl module as I mentioned is a bit different - it has
functional parts which could be in fact separate extensions, but for
practical reasons aren't. So
Then the name of the extension is wrong.
Well, that's what we could do. You are welcome to propose a better one :)
But this way we get an overflow of prefixes. And I'd prefer grouped
functionality to share prefixes.
We don't have any limit on how many prefixes we can have, so I don't see
49 matches
Mail list logo
