Hi!
Norbert Lindenberg ☮ wrote:
I like Guillaume's proposal - use Collator and Locale as is for 5.2,
make them Intl::Collator and Intl::Locale when namespaces are available,
i.e., from 5.3.
Would that work for everybody? How much effort is it to implement this?
If we make this exclusively,
tex
> -Original Message-
> From: Norbert Lindenberg ☮ [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 11:34 PM
> To: Guillaume Rossolini
> Cc: Norbert Lindenberg ☮; Darren Cook; Stanislav Malyshev;
> php-i18n@lists.php.net
> Subject: Re: [PHP-I18N] intl 1.0.0R
Zitat von Lars Strojny <[EMAIL PROTECTED]>:
Hi,
Am Freitag, den 13.06.2008, 23:34 -0700 schrieb Norbert Lindenberg ☮:
Would that work for everybody? How much effort is it to implement
this?
+1 for this solution. Stas, what do you think?
That would work for me too.
Jan.
--
Do you need pro
Hi,
Am Freitag, den 13.06.2008, 23:34 -0700 schrieb Norbert Lindenberg ☮:
> Would that work for everybody? How much effort is it to implement
> this?
+1 for this solution. Stas, what do you think?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
I like Guillaume's proposal - use Collator and Locale as is for 5.2,
make them Intl::Collator and Intl::Locale when namespaces are
available, i.e., from 5.3.
Would that work for everybody? How much effort is it to implement this?
Norbert
On Jun 10, 2008, at 02:44 , Guillaume Rossolini wrot
Hi!
I don't. Maybe you do. Or, rather, Zend does. So the Zend Framework can
use it, I guess.
Do you seriously argue that I have to redesign the extension, throwing
out all the original requirements for all the participating parties in
the project and all people who contributed to it and alre
It wasn't Zend. Other companies wanted it in 5.2.
tex
> -Original Message-
> From: David Zülke [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 10, 2008 4:14 AM
> To: Stanislav Malyshev
> Cc: Darren Cook; php-i18n@lists.php.net
> Subject: Re: [PHP-I18N] intl 1.0.
Hi!
What kind of attitude is that? You personally think it sucks, so it's
not going to happen?
Not only myself, but myself too. Why do you think that your opinion
matters but mine and everybody's that agrees with me doesn't?
It's not artificial or awkward at all, it's poor man's namespacing
Am 10.06.2008 um 09:02 schrieb Stanislav Malyshev:
Hi!
What are the good reasons for not changing the names?
This was already discussed on the list, so reading the archives
would help. But OK, here it goes again:
1. We want the extension to be in 5.2 to 6.x
I don't. Maybe you do. Or, r
aim or what did you have to do to introduce date class
that is relevant?
tex
> -Original Message-
> From: Jan Schneider [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 10, 2008 3:33 AM
> To: php-i18n@lists.php.net
> Subject: Re: [PHP-I18N] intl 1.0.0RC1
>
> Zi
Zitat von "Stanislav Malyshev" <[EMAIL PROTECTED]>:
Hi!
Yes. Why can't it be IntlCollator in both 5.x and 6.x? In other words
(unless I'm missing something) compatibility between 5.x and 6.x doesn't
affect the naming choice.
The thing is that having collators in PHP called IntlCollator and
Hi,
Here's my user point of view, if you don't mind.
I think your argument is about namespaces, which will be in 6 but not
5.2... So you might want to have IntCollator and IntLocale in 5.2 to avoid
possible collisions, but you would rather have something like Intl::Collator
and Intl::Locale from
Hi!
Yes. Why can't it be IntlCollator in both 5.x and 6.x? In other words
(unless I'm missing something) compatibility between 5.x and 6.x doesn't
affect the naming choice.
The thing is that having collators in PHP called IntlCollator and
locales in PHP called IntlLocale sucks. It looks so aw
>> I don't understand why the choice between IntlCollator and Collator
>> affects compatibility between 5.x and 6.x. Can you explain this further?
>
> Because if you want Collator in 6, and you want same code to run both
> 5.x and 6.x, then it's Collator in 5.x. If A==B, then B==A.
Yes. Why can't
Hi!
I don't understand why the choice between IntlCollator and Collator
affects compatibility between 5.x and 6.x. Can you explain this further?
Because if you want Collator in 6, and you want same code to run both
5.x and 6.x, then it's Collator in 5.x. If A==B, then B==A.
I don't think I
>> What are the good reasons for not changing the names?
>
> 1. We want the extension to be in 5.2 to 6.x
> 2. We want PHP source code compatibility between 5.x and 6.x code
I don't understand why the choice between IntlCollator and Collator
affects compatibility between 5.x and 6.x. Can you expl
Hi!
What are the good reasons for not changing the names?
This was already discussed on the list, so reading the archives would
help. But OK, here it goes again:
1. We want the extension to be in 5.2 to 6.x
2. We want PHP source code compatibility between 5.x and 6.x code
3. We want PHP 6 u
>> Finally, I would like to point you to
>> http://www.php.net/manual/en/userlandnaming.rules.php:
>> "PHP will prefix any global symbols of an extension with the name of
>> the extension."
>
> That's not what the real coding standard says:
>
> If they are part of a "parent set" of functions, th
Finally, I would like to point you to
http://www.php.net/manual/en/userlandnaming.rules.php:
"PHP will prefix any global symbols of an extension with the name of the
extension."
That's not what the real coding standard says:
If they are part of a "parent set" of functions, that parent should
Zitat von "Stanislav Malyshev" <[EMAIL PROTECTED]>:
Hi!
Then do the right thing and make it PHP 5.3+ and namespace it right
from the beginning.
I'd be glad to, but it has to work with 5.2. I would like to make it
"ideal" way, but there are real world problems that needs to solve
which i
Hi!
Stanislav, does the above mean that IntlDateFormatter will be renamed to
DateFormatter, and be inside a namespace, for php 6?
What I'd like to happen is for DateFormatter to become part of DateTime
- i.e. recommended usage would be not using IntlDateFormatter at all but
have format funct
>>> Obviously, it is less likely that someone who wrote a Collator called
>>> their class "IntlCollator" instead of "Collator".
Stanislav Malyshev wrote:
>> But we want to use Collator name, because we want to use these classes
>> in PHP 6, and we want PHP collation be called Collator, just as PHP
Hi!
Then do the right thing and make it PHP 5.3+ and namespace it right from
the beginning.
I'd be glad to, but it has to work with 5.2. I would like to make it
"ideal" way, but there are real world problems that needs to solve which
intervene :)
The inconsistency is that one class, IntlDa
Am 04.06.2008 um 14:44 schrieb Stanislav Malyshev:
Hi!
Obviously, it is less likely that someone who wrote a Collator
called their class "IntlCollator" instead of "Collator".
But we want to use Collator name, because we want to use these
classes in PHP 6, and we want PHP collation be call
Hi!
Obviously, it is less likely that someone who wrote a Collator called
their class "IntlCollator" instead of "Collator".
But we want to use Collator name, because we want to use these classes
in PHP 6, and we want PHP collation be called Collator, just as PHP date
functions are called Dat
Hi!
How about
$arr = array(
'language' => 'en',
'script' => 'Hans',
'region' => 'CN',
'variants' => array(
'rozaj',
'nedis',
),
'privates' => array(
'prv1',
'prv2',
),
);
echo Locale::composeLocale($arr);
Nice idea, please add a feature request. Maybe even be
You mean http://docs.php.net/manual/en/locale.composelocale.php ?
I just looked at that for the first time.
It is utterly frightening. You can't possibly be serious about this:
$arr = array(
'language' => 'en',
'script' => 'Hans',
'region' => 'CN',
'variant2' => 'rozaj',
'variant1
Am 02.06.2008 um 07:36 schrieb Stanislav Malyshev:
Hi!
What if there is a Number extension down the road. Or a Collator
extension. Or what if people already have classes called
NumberFormatter
Well, what if they have classes named IntlNumberFormatter? There can
be
all kinds of classes,
Hi!
$locale = new IntlLocale();
$locale->setCurrency(IntlCurrency::USD);
$locale->setCollation(IntlCollation::TRADITIONAL);
You have functions for that in Locale class.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED
Hi Stas,
(sorry for the cluttered reply)
Am Montag, den 02.06.2008, 08:36 +0300 schrieb Stanislav Malyshev:
> Because locale is essentially the string. There's nothing in the
> locale that isn't in the string, so you don't need any specific object
> for that - it wouldn't give you any value.
Exc
Hi Stas,
Am Montag, den 02.06.2008, 08:36 +0300 schrieb Stanislav Malyshev:
> Well, what if they have classes named IntlNumberFormatter? There can
> be all kinds of classes, and until we have standard namespace for
> internal classes we have to live with names being global and make them
> sufficie
Hi!
What if there is a Number extension down the road. Or a Collator
extension. Or what if people already have classes called NumberFormatter
Well, what if they have classes named IntlNumberFormatter? There can be
all kinds of classes, and until we have standard namespace for internal
classes
> - I still think IntlDateFormatter vs the rest w/o Intl prefix is
> inconsistent. Can't we just prefix it with "Intl" across the board?
> Saves trouble down the road
I'd like to second this proposal. Consistency and
far-less-likely-to-clash-with-existing-code are more important (IMHO)
than slight
Am 01.06.2008 um 07:43 schrieb Stanislav Malyshev:
Hi!
- I still think IntlDateFormatter vs the rest w/o Intl prefix is
inconsistent. Can't we just prefix it with "Intl" across the board?
Saves trouble down the road
Because frankly this prefix sucks and so do names like
IntlMessageForma
Hi!
- I still think IntlDateFormatter vs the rest w/o Intl prefix is
inconsistent. Can't we just prefix it with "Intl" across the board?
Saves trouble down the road
Because frankly this prefix sucks and so do names like
IntlMessageFormatter. In order to avoid conflict with Date extension I
Hi Stas,
some things we noticed:
- I still think IntlDateFormatter vs the rest w/o Intl prefix is
inconsistent. Can't we just prefix it with "Intl" across the board?
Saves trouble down the road
- DateFormatter::parse() and DateFormater::localtime() should have the
second argument ($parse
>> I don't have a configure.in (under either /usr/include/php5 or
>> /usr/lib/php5), and no references to ptrdiff or PTRDIFF inside any file
>> in /usr/lib/php5/build.
>
> You are supposed to have configure.in - it's part of PHP source. Do you
> use binary install? If so, which version?
ubuntu 7.
> Well, I'm not sure how these macros can be included without conflicting
> with 5.2.4 where these macros are already defined in system config. If
> you know how to do it please send a patch.
A quick bit of study suggests it most likely "just works", as long as
you have square brackets around the
Hi!
The only ptrdiff reference in php_config.h is:
/* The size of `ptrdiff_t', as computed by sizeof. */
#define SIZEOF_PTRDIFF_T 4
That's strange -
I don't have a configure.in (under either /usr/include/php5 or
/usr/lib/php5), and no references to ptrdiff or PTRDIFF inside any file
in /usr
> Well, I'm not sure how these macros can be included without conflicting
> with 5.2.4 where these macros are already defined in system config.
Sorry, I don't know either. It seems like redefining a macro should be a
common need however.
> Something is wrong here - this line is specifically surro
Hi!
It now refuses to install on php 5.2.3, i.e. ubuntu 7.10. (Wasn't the
plan to include the required macros in the ./configure script (or
whatever) so that it could install on more PHP installations.)
Well, I'm not sure how these macros can be included without conflicting
with 5.2.4 where
> I've uploaded 1.0.0RC1 version of intl extension on PECL. Please test it
> and if you think anything has to be added/fixed for 1.0.0 please tell.
It now refuses to install on php 5.2.3, i.e. ubuntu 7.10. (Wasn't the
plan to include the required macros in the ./configure script (or
whatever) so
Hooray!
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 27, 2008 2:27 PM
> To: php-i18n@lists.php.net
> Subject: [PHP-I18N] intl 1.0.0RC1
>
> Hi!
>
> I've uploaded 1.0.0RC1 version of intl extension on PE
Hi!
I've uploaded 1.0.0RC1 version of intl extension on PECL. Please test it
and if you think anything has to be added/fixed for 1.0.0 please tell.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Unicode & I1
44 matches
Mail list logo
