php-i18n Digest 6 Jun 2008 22:33:32 -0000 Issue 399
Topics (messages 1239 through 1246):
Re: intl 1.0.0RC1
1239 by: David Zülke
1240 by: Stanislav Malyshev
1241 by: Stanislav Malyshev
1242 by: David Zülke
1243 by: Stanislav Malyshev
1244 by: Darren Cook
1245 by: Stanislav Malyshev
1246 by: Jan Schneider
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
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' => 'nedis',
'private1' => 'prv1',
'private2' => 'prv2'
);
echo Locale::composeLocale($arr);
I may use private0, private1, ... private14?
How about
$arr = array(
'language' => 'en',
'script' => 'Hans',
'region' => 'CN',
'variants' => array(
'rozaj',
'nedis',
),
'privates' => array(
'prv1',
'prv2',
),
);
echo Locale::composeLocale($arr);
- David
Am 03.06.2008 um 12:50 schrieb Stanislav Malyshev:
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]
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
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 better would be to
allow "private"/"variant" to be both string and array (now it can be
only string).
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
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 DateTime and PHP's COM handling class is called
COM, even though somebody could have their own implementation of COM and
date/time handling.
complain about. This should really be changed to be consistent across
the board, Stas.
I don't see why adding unnecessary prefixes to function names would add
anything. When you want to do collation, you expect your class to be
named "collator", and when you want to deal with locales, you want the
class to be named "locale". What's "inconsistent" in that - that they
start from different letters?
I mean who are you/we to decide that someone from the Republic of
Serbia, who speaks Serbian, may not view sales numbers for last week's
month in the thai-buddhist calendar in USD and sorted "traditionally"?
I don't decide anything on which locales people use. Though people that
actually work in the i18n field says using such locales are extremely
rare, and I believe them.
But in any case, you don't need yo use calendar for collator, and you
don't need to use currency for date/time formatting.
Please tell that to the ICU library developers. 98-byte long locale
provably crashes ICU libraries. I didn't want to take chances so I chose
smallest "round" number for the limit that works reliably. I'd be
happy to raise it if I could be sure ICU would work OK with it.
97? ;)
I can't be really sure any other ICU function wouldn't crash on any
other OS on 97. I could raise it, but how 97 is that better than 64? If
you suppose people stuff everything and a kitchen sink there, 97 could
be as easily overrun. If you base on most frequent usage, 64 is more
than enough. If there's a case to be made for making it not 64 but any
other number, I'm ready to hear it - but I want some real-life data on it.
But you have to parse the locale string each time, right? That is
No, I don't. ICU API takes char*.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
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 called Collator, just
as PHP date functions are called DateTime and PHP's COM handling
class is called COM, even though somebody could have their own
implementation of COM and date/time handling.
Then do the right thing and make it PHP 5.3+ and namespace it right
from the beginning.
complain about. This should really be changed to be consistent
across the board, Stas.
I don't see why adding unnecessary prefixes to function names would
add anything. When you want to do collation, you expect your class
to be named "collator", and when you want to deal with locales, you
want the class to be named "locale". What's "inconsistent" in that -
that they start from different letters?
The inconsistency is that one class, IntlDateFormatter, has a prefix.
And the others do not.
I mean who are you/we to decide that someone from the Republic of
Serbia, who speaks Serbian, may not view sales numbers for last
week's month in the thai-buddhist calendar in USD and sorted
"traditionally"?
I don't decide anything on which locales people use. Though people
that actually work in the i18n field says using such locales are
extremely rare, and I believe them.
But in any case, you don't need yo use calendar for collator, and
you don't need to use currency for date/time formatting.
That is correct.
However, that means I would need to parse a locale string, extract
only the information I need for a particular task, and pass a new
locale string containing only the relevant information.
This cannot be the point of this extension, Stas. It must make my life
easier, not more complicated.
Like with the sort() method, it is completely wrong to expose
implementational details through the API. And that's what this is doing.
We've ported several parts of ICU to PHP code. We know the problems
and the situations that arise. We have quite some experience in
building and designing a proper API. Please trust me here.
Please tell that to the ICU library developers. 98-byte long locale
provably crashes ICU libraries. I didn't want to take chances so I
chose
smallest "round" number for the limit that works reliably. I'd be
happy to raise it if I could be sure ICU would work OK with it.
97? ;)
I can't be really sure any other ICU function wouldn't crash on any
other OS on 97. I could raise it, but how 97 is that better than 64?
If you suppose people stuff everything and a kitchen sink there, 97
could be as easily overrun. If you base on most frequent usage, 64
is more than enough. If there's a case to be made for making it not
64 but any other number, I'm ready to hear it - but I want some real-
life data on it.
I gave you the Chinese example already. 65 chars. And this _will_
occur in the wild, believe me. The fun thing about i18n is that the
strangest things you couldn't possibly imagine can occur.
But you have to parse the locale string each time, right? That is
No, I don't. ICU API takes char*.
Right. IIRC, they accept objects, too. The NumberFormatter accepts
only locale objects AFAIK.
Cheerio,
David
--- End Message ---
--- Begin Message ---
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, IntlDateFormatter, has a prefix.
And the others do not.
Think of it as part of the name, not prefix. I'd like to keep it
DateFormatter, but Derick wants "Date" word for himself :)
However, that means I would need to parse a locale string, extract only
the information I need for a particular task, and pass a new locale
string containing only the relevant information.
Well, most probably you don't need to parse it, you are the one that's
composing it - I see no use case where you would get that complex
kitchen-sink locale name from an external source. What you'd get
probably is either the language name or the language ID, and maybe
country name/ID - e.g. from configuration UI - or short locale name from
DB, etc.
Like with the sort() method, it is completely wrong to expose
implementational details through the API. And that's what this is doing.
Here I have little choice - either to allow it to segfault or to have
checks. I wish ICU programmers weren't sloppy, but they are and purpose
of this extension is to write ICU wrapper not to reimplement it.
If you volunteer to write code that would allow to sanitize locale
strings without imposing this limit - I am more than happy to accept it.
Right. IIRC, they accept objects, too. The NumberFormatter accepts only
locale objects AFAIK.
I'm afraid you are confusing C and C++ API.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
>>> 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
>> date functions are called DateTime and PHP's COM handling class is
>> called COM, even though somebody could have their own implementation
>> of COM and date/time handling.
David Zülke wrote:
> Then do the right thing and make it PHP 5.3+ and namespace it right from
> the beginning.
Stanislav, does the above mean that IntlDateFormatter will be renamed to
DateFormatter, and be inside a namespace, for php 6?
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting demos)
--- End Message ---
--- Begin Message ---
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 functions of DateTime that use ICU. But IntlDateFormatter
would probably stay for 5.x support.
As for implementing namespaces for PHP extensions - this is a big topic,
which I think should be discussed on the main list. If it will be done,
then of course it will also be done on intl extension.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
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 intervene :)
The inconsistency is that one class, IntlDateFormatter, has a
prefix. And the others do not.
I have to wholeheartedly agree with David. You are calling for
problems if *not* prefixing everything. See below.
Think of it as part of the name, not prefix. I'd like to keep it
DateFormatter, but Derick wants "Date" word for himself :)
Yes, and he wants it for a good reason, namely because he's gone
through all the trouble with the date extension already. Stas, you've
been around at that time already, so you know the "date" disaster back
then. And after many few-hundred-messages threads it was decided that
the new classes introduced with PHP 5.1.0 have to be prefixed with
Date, and that this has to happen for all new classes.
You also know pretty well that inconsistency is one of the most
frequent criticisms on PHP. You are making this worth with introducing
more inconsistencies in such a central piece of PHP.
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."
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
--- End Message ---
