> -Original Message-
> From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 23, 2008 7:12 AM
> To: Steph Fox
> Cc: Tex Texin; Marcus Boerger; Pierre Joye; [EMAIL PROTECTED];
PHP
> Developers Mailing List
> Subject: Re: [PHP-DEV] Re: [php-icu] Grapheme
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
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 f
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? N
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
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 ne
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
Precisely. It was never a "secret", despite someone's paranoidal
proclaiments..
-Andrei
Stanislav Malyshev wrote:
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
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.
--
-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
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 annou
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 grea
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
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 extensio
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.
>
>
AM
To: Tex 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.
Thi
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
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
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
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 underst
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 shoul
tex
-Original Message-
From: Marcus 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:
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"
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 ther
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,
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
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 p
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
an
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 leav
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,
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 pre
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
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, A
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
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 na
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 dependen
gs 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
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
> > > exten
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 d
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
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 nam
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
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 conflict? I think it
should have been caught b
51 matches
Mail list logo
