Re: intl naming
| From: | Pierre Joye | Date: | Wed, 16 Apr 2008 13:21:49 +0000 |
| Subject: | Re: intl naming | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-37035@lists.php.net to get a copy of this message | ||
Hi,
On Tue, Apr 15, 2008 at 12:35 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> > > to know what to think about my API changes proposal and the exception
> > > usages as it is a relatively important request. Or why are you asking?
> > >
> >
> > I already stated my opinion about exceptions - I consider using them
> > inappropriate in the context of this extension. However, my question was not
> > about redesigning the API, but specifically about names.
>
> I'm not sure how I should understand that. Does that mean that there
> is no room to discuss or change anything in intl as long as you don't
> agree? It may be asked in a rude way but I have hard time to follow
> the logic behind your requests.
>
>
> > > I really fear to suddenly see a 1.0.0-stable with none of our requests
> > > inside.
> > >
> >
> > That depends on the requests and timeframe for their execution. Since we
> > have mostly done the work that was planned for 1.0, I want to close one
> > question that may change API. Adding features and enhancements is good, but
> > not right now. If you wish, you may document them as feature requests for
> > intl package on pecl too.
>
> My point did not change. I do think that it is premature for
> 1.0.0-stable. I understand that you like to be at this stage for the
> end of this month (5.3) but I don't think we have to hurry up without
> solving the obvious issues we have. The API is the biggest one.
Let me know if I should simply consider than any change to the API
will be rejected. That will spare me (and other too) some time as I
will not try to provide patches or improvements if they will be
rejected anyway. But no answer is not a no and feed the confusion.
> > No trick, just checked out the code, put the libs in ../icu, run configure
> > and nmake.
>
> Checked out? You mean with CVS/SVN? I thought you were using their releases.
I will post my ICU questions to ICU support, faster :)
Please find a patch as attachment, fixing some bad #ifdef. This test
should be in the main intl header, imo.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Index: msgformat/msgformat_format.c =================================================================== RCS file: /repository/pecl/intl/msgformat/msgformat_format.c,v retrieving revision 1.1.2.7 diff -u -r1.1.2.7 msgformat_format.c --- msgformat/msgformat_format.c 5 Mar 2008 21:22:12 -0000 1.1.2.7 +++ msgformat/msgformat_format.c 16 Apr 2008 11:02:19 -0000 @@ -27,8 +27,8 @@ #include "msgformat_helpers.h" #include "intl_convert.h" -#ifndef Z_ADDREF_P(z) -#define Z_ADDREF_P(z) ((z)->refcount++) +#ifndef Z_ADDREF_P +# define Z_ADDREF_P(z) ((z)->refcount++) #endif
Index: msgformat/msgformat_format.c =================================================================== RCS file: /repository/pecl/intl/msgformat/msgformat_format.c,v retrieving revision 1.1.2.7 diff -u -r1.1.2.7 msgformat_format.c --- msgformat/msgformat_format.c 5 Mar 2008 21:22:12 -0000 1.1.2.7 +++ msgformat/msgformat_format.c 16 Apr 2008 11:02:19 -0000 @@ -27,8 +27,8 @@ #include "msgformat_helpers.h" #include "intl_convert.h" -#ifndef Z_ADDREF_P(z) -#define Z_ADDREF_P(z) ((z)->refcount++) +#ifndef Z_ADDREF_P +# define Z_ADDREF_P(z) ((z)->refcount++) #endif