Stanislav Malyshev wrote:
> Hi!
>
>> Forgot to attach a second for config.w32, to nicely detect the
>> required libraries.
>
> Why do you think it is necessary to check each lib individually? Those
> libs are distributed together, and unless you mess with your ICU
> install, they should be always
On Wed, Apr 16, 2008 at 8:11 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > Forgot to attach a second for config.w32, to nicely detect the
> > required libraries.
> >
>
> Why do you think it is necessary to check each lib individually? Those libs
> are distributed together, and
Please find a patch as attachment, fixing some bad #ifdef. This test
should be in the main intl header, imo.
Applied, thanks.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
Hi!
Forgot to attach a second for config.w32, to nicely detect the
required libraries.
Why do you think it is necessary to check each lib individually? Those
libs are distributed together, and unless you mess with your ICU
install, they should be always found together, so if icuuc.lib is the
On Wed, Apr 16, 2008 at 3:21 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> Please find a patch as attachment, fixing some bad #ifdef. This test
> should be in the main intl header, imo.
Forgot to attach a second for config.w32, to nicely detect the
required libraries.
Cheers,
--
Pierre
http://
Hi,
On Tue, Apr 15, 2008 at 12:35 AM, Pierre Joye <[EMAIL PROTECTED]> 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 -
Hi!
On Tue, Apr 15, 2008 at 12:17 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I hope you are keeping in mind our last discussion here. I also like
> >
>
> Yes, I do.
Great, thanks :)
> > to know what to think about my API changes proposal and the exception
> > usages as it is a relat
Hi!
I hope you are keeping in mind our last discussion here. I also like
Yes, I do.
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 t
On Mon, Apr 14, 2008 at 11:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi all!
>
>
>
> > I wanted to ask the people here for opinions on the subject of functions
> naming in pecl/intl (hopefully soon to be ext/intl ;) module. Current state
> can be seen at http://docs.php.net/manual/en/b
Hi all!
I wanted to ask the people here for opinions on the subject of functions
naming in pecl/intl (hopefully soon to be ext/intl ;) module. Current
state can be seen at http://docs.php.net/manual/en/book.intl.php
Since publishing this mail about 2 weeks ago I have received a number of
rep
On Wed, Apr 9, 2008 at 9:01 AM, David Zülke <[EMAIL PROTECTED]> wrote:
> Sure, but you need to remember that this means someone has to maintain the
> mappings.
>
> Mind you that pretty much any locale-related information is in the CLDR
> already - language, territory and timezone mappings, for i
Am 09.04.2008 um 08:48 schrieb Pierre Joye:
On Wed, Apr 9, 2008 at 12:07 AM, David Zülke <[EMAIL PROTECTED]>
wrote:
Note that most of this info is already in the CLDR info. And I am
with Stas
here, not sure if it's really necessary. You can do this mapping by
hand, if
necessary, but trust me
On Wed, Apr 9, 2008 at 4:06 AM, Steph Fox <[EMAIL PROTECTED]> wrote:
> This isn't how PHP used to be. This is a whole new way of coding, and you'd
> like to force it onto people who never did that CS degree, but who coped
> just fine until now. How sweet.
Right, however I think you underestimate
On Wed, Apr 9, 2008 at 12:07 AM, David Zülke <[EMAIL PROTECTED]> wrote:
> Am 08.04.2008 um 21:09 schrieb Pierre Joye:
> > It is amazingly handy to know that a locale given by the user (UI or a
> > developer using your library) is valid. What I like to have are
> > getCountry, getISO3* etc. I can p
Steph Fox wrote:
> So please, yes, keep the procedural way as an option, make it possible
> for people to use PHP without their having to be computer scientists
> first. The moment the language loses that, it has nothing special to
> offer any more.
+1 Nothing beats procedural for the quick and di
I also agree on the DateTime thing, and I, too, wonder why we need a
procedural API for this - especially since it makes error handling so
much easier (exceptions everywhere and done).
Sure. If you happen to be one of the few PHP users who puts everything into
try/catch blocks as a matter of c
Am 08.04.2008 um 21:09 schrieb Pierre Joye:
The idea is to have a way to get a code for a language, or to
valid a
given code, etc. Many applications actually duplicate this list
internally, it would be very nice to be able to deal with the ICU
lists (display, validation, listings, etc.).
You
Off the top of my head, ICU has this "path" style syntax to query CLDR
data. I think that would be pretty important - the data is there, and
grabbing it shouldn't be too difficult (can't check right now, but
it's something like $locale->getInfo('currencyNames/EUR/long') or
whatever).
I al
Hi!
Will you agree to extend the Locale API to provide more informations?
If it makes sense and consistent with what ICU has - sure.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime D
re,
On Tue, Apr 8, 2008 at 9:35 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > It is amazingly handy to know that a locale given by the user (UI or a
> > developer using your library) is valid. What I like to have are
> >
>
> What is "valid"? Database can have no exact match for locale str
Hi!
It is amazingly handy to know that a locale given by the user (UI or a
developer using your library) is valid. What I like to have are
What is "valid"? Database can have no exact match for locale string, but
still have some data from fallbacks, etc.
getCountry, getISO3* etc. I can prov
>> As for validity, since locale mechanism has a bunch of fallbacks, I
>> understand the validity concept is a bit blurred. I.e. you can have
>> regexp
>> to check all the -'s or _'s are in place but beyond that it's kind of
>> hard
>> to know what the question "is en_RU locale valid?" means.
>
>
Hi!
On Tue, Apr 8, 2008 at 8:53 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I did not find a way to do it in the manual or in the code. How do I
> > set in PHP? And how is it possible to use it as default for all
> > further calls (no matter which class/method)?
> >
>
> Locale::setDefa
Hi!
I did not find a way to do it in the manual or in the code. How do I
set in PHP? And how is it possible to use it as default for all
further calls (no matter which class/method)?
Locale::setDefault() and Locale::DEFAULT.
That's why I would prefer an array (as named arguments). The keys
Hi Stan,
On Tue, Apr 8, 2008 at 7:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > The ICU API solves this issue nicely using the current locale. It
> > would be easier to work with the intl API if the same principle was
> > used. Add a Locale::setDefault() and Locale::getDefault().
Hi!
The ICU API solves this issue nicely using the current locale. It
would be easier to work with the intl API if the same principle was
used. Add a Locale::setDefault() and Locale::getDefault().
You can use default locale, of course, and Locale class already has
these functions. ht
ine; PHP internals
>
> > Subject: Re: [PHP-DEV] intl naming
> >
> >
> > It is also amazing to systematically ignore my comments about your off
> > list discussions (same in Andi's reply).
> >
>
> Actually I didn't. Go and read my answer fr
Hi!
What about
a) an "ICU" prefix?
I don't think it's better than intl_, having disadvantage of referring
to particular library rather than function (like glibc_file_get_contents
instead of file_get_contents).
b) daring the leap and use namespaces, making it 5.3+ only (I know, that
wasn't
What about
a) an "ICU" prefix?
b) daring the leap and use namespaces, making it 5.3+ only (I know,
that wasn't the plan, but maybe it would be a good idea)
David
--
David Zülke
[EMAIL PROTECTED]
Tel: +49 (0)89 57 08 15 15
Fax: +49 (0)89 57 08 15 17
bitXtender GbR
Paul-Heyse-Straße 6
80336 Mü
> -Original Message-
> From: Pierre Joye [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 04, 2008 12:33 PM
> To: Stas Malyshev
> Cc: Lester Caine; PHP internals
> Subject: Re: [PHP-DEV] intl naming
>
>
> It is also amazing to systematically ignore my com
On Fri, Apr 4, 2008 at 9:27 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > Yes, please tell us your "long" term plan/roadmap/todo, what is the
> > remaining work in intl and unicode, in php6 (from a ICU integration
> > point of view). We have a wonderful tool to document such tas
Hi!
Yes, please tell us your "long" term plan/roadmap/todo, what is the
remaining work in intl and unicode, in php6 (from a ICU integration
point of view). We have a wonderful tool to document such tasks very
efficiently at http://wiki.php.net. Doing so may help you to do not be
"out of resource
Hi Stan,
On Fri, Apr 4, 2008 at 8:47 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > PLEASE - what is stopping PHP6 becoming a platform that we can start
> working with today?
> >
>
> There's a lot of work still for integrating intl extension with PHP 6 (and
> PHP 5 too), please tell me wh
Hi!
THAT I agree with - BUT WHAT IS STOPPING PHP6 being the solution. I
can't see any reason that time is being wasted on yet another PHP5.X
when that same effort could be directed to getting at least a stable
beta of PHP6 out the door?
I'm sorry you don't see the reason, but we do. The reas
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2008 4:37 AM
To: Tex Texin
Cc: Lester Caine; PHP internals
Subject: RE: [PHP-DEV] intl naming
Tex,
please please quote properly, it is really hard to follow the conversion down
below here. http
Tex,
please please quote properly, it is really hard to follow the conversion
down below here. http://www.netmeister.org/news/learn2quote.html has
some good information on this topic.
regards,
Derick
On Fri, 4 Apr 2008, Tex Texin wrote:
> Lester asks:
>
> THAT I agree with - BUT WHAT IS STO
Lester asks:
THAT I agree with - BUT WHAT IS STOPPING PHP6 being the solution. I can't see
any reason that time is being wasted on yet another PHP5.X when that same
effort could be directed to getting at least a stable beta of PHP6 out the door?
Tex replies:
When we started this project nearly
Stanislav Malyshev wrote:
Hi!
I suppose the main question here is the simple one.
Will PHP6 be integrally - unicode?
Sure, it will :)
run anything else - use PHP5 for an 'ascii' based version ) then why
are we discussing separating out functions which are part of that core.
Because we nee
Hi!
On the API side have you considered throwing exceptions instead of
checking error statuses? Also would it not be useful to have the
We considered it and decided against it.
DateFormatter optionally accept DateTime instances in addition to
strings?
It is planned to be added after we rel
Hi!
Is there any chance this is not going to be available for 5.2?
No. One of the goals was to provide 5.2 support from the start, to
enable large projects (read: no way switching to 5.3 soon after the
release) to start using it ASAP.
Because if so, I would add another option to the namin
Hi!
I suppose the main question here is the simple one.
Will PHP6 be integrally - unicode?
Sure, it will :)
run anything else - use PHP5 for an 'ascii' based version ) then why are
we discussing separating out functions which are part of that core.
Because we need them much sooner than PHP
Stanislav,
I like the look of the API. The naming convention appears logical, on
the question of internal class names existing in userland I'm sure
people will refer to the discussions around DateTime.
Many extensions appear to offer procedural style equivalents to the OOP
API, personally I think
Hi,
naming classes/function is really an important concern and I'm happy that such
a thing gets a dedicated thread finally.
Stanislav Malyshev wrote:
internationalization capabilities of the ICU library to PHP 5,
specifically 5.2.x and 5.3.x branches. We felt that as PHP gets more and
Is t
Stanislav Malyshev wrote:
Hi!
I wanted to ask the people here for opinions on the subject of functions
naming in pecl/intl (hopefully soon to be ext/intl ;) module. Current
state can be seen at http://docs.php.net/manual/en/book.intl.php
I suppose the main question here is the simple one.
Wi
44 matches
Mail list logo
