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
First, a bit of background.
Intl extension project was created with the purpose to bring
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
more enterprise adoption, it needs to start supporting internationalized
development much sooner than PHP 6 roadmap would allow us to. Thus, the
goals of the project were chosen as follows:
- Provide dual OO/procedural API for all functions
- Provide same PHP API for both PHP 5 and PHP 6, to allow easy
migration in the future - Keep same codebase in 5.x versions and keep codebases between 5 and 6
as close as possible - Have separate functional modules for each functionality piece (number
formatter, locale handling, collator, normalization, etc.) with intend
to add more modules as we go, while keeping single extension as an
umbrella for them.
As a consequence, we arrived at the naming scheme we have now in
pecl/intl, i.e. classes named as NumberFormatter, MessageFormatter,
DateFormatter, Collator, etc. and functions named as numfmt_, msgfmt_,
collator_, datefmt_. The latter were chosed in accordance to the
guidelines stated at http://www.php.net/reST/php-src/CODING_STANDARDS,
saying:
If they [function names - SM] are part of a "parent set" of functions,
that parent should be included in the user function name, and should be
clearly related to the parent program or function family. This should be
in the form of parent_*.
Recently, concerns were raised specifically about the name
DateFormatter, which can potentially infringe on ext/date namespace, and
in general about all the names. There were proposals to prefix all class
and function names with Intl and intl_ respectively. While I feel that
would make the API unnecessarily cluttered (since each module will have
to keep its prefix anyway, we'd have stuff like
intl_numfmt_parse_currency which IMO looks much uglier than
numfmt_parse_currency, same goes for IntlCollator vs. Collator, etc.)
However, technically it is possible to do such change, and I believe if
it has to be done it has to be done now, when we have first phase of the
development feature-complete and ready (up to bugfixes here and there)
to announce the module as 1.0 version for everybody to use.
So, I propose people to consider all the above and the following options:
-
Leave it as is.
Pro: we have it now and it works, and it looks nice.
Contra: see above -
Rename only problematic one - DateFormatter to IntlDateFormatter
Pro: minimal change, nice names stay and can be used in PHP 6 API too.
Contra: one piece starts with Intl, others don't - API looks weird as a
whole -
Rename all classes to Intl* while leaving functions as is
Pro: All classes in the extension look the same, functions still have
nice names
Contra: All classes get ugly names, and they are going to stay in PHP 6
where those will be recommended system classes (so not Locale but
IntlLocale, not Collator but IntlCollator). -
Rename both classes and functions.
Pro: All API looks the same, purists are happy
Contra: API looks ugly, too many prefixes for functions.
So, please comment. If you have more ideas on the topic, please feel
welcome to propose. We want to make this decision ASAP, so that we could
move forward with the extension release.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
Will PHP6 be integrally - unicode?
Personally I WANT a clean character set free base to work from and that is
what I was under the impression that PHP6 was going to provide. If the core is
running unicode ( and I see no logical reason why it should run anything else
- use PHP5 for an 'ascii' based version ) then why are we discussing
separating out functions which are part of that core.
The core objects should properly handle unicode, so why have DUPLICATE
functions such as Date and DateFormatter at all? Number and possibly Currency
should also exist in the same way as Date? Collation is as much part of
database handling as array, and upper and lower functions are not being moved
TO intl so why should there be different handling of things.
I had expected to be running PHP6 in a clean UTF-8 mode by now, and that
functions like localeconv would simply work. If that is not the intention for
PHP6 then perhaps we need to start looking to a replacement of PHP6 already :(
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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 6 would be released. We need
them yesterday.
The core objects should properly handle unicode, so why have DUPLICATE
functions such as Date and DateFormatter at all? Number and possibly
We don't duplicate them, we add them.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 need them much sooner than PHP 6 would be released. We need
them yesterday.
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?
The core objects should properly handle unicode, so why have DUPLICATE
functions such as Date and DateFormatter at all? Number and possiblyWe don't duplicate them, we add them.
intl itself is a duplication or rather creation of additional functions which
SHOULD simply be provided by the core functions.
MessageFormatter simply duplicates and complicates a simple display of a
message with embedded variables. If I ask for to output a string with
variables in using a different locale then the DATE variables should simple
display the correct format for that locale. I should not have to go through
all the code and re-write the variables in some complex format so another
package can then do the same job that the core system IS ALREADY DOING?
Collator is already required to process strtoupper and strtolower, so why
should we need to decide if we can use them or we need to create a new object
and get that to do the job.
PLEASE - what is stopping PHP6 becoming a platform that we can start working
with today?
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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 a year ago (earlier when I started lobbying Yahoo for resources for it) I naively imagined the project would be a few months. As PHP 6 was more than a year away and I suspected it would drift further into the future, it seemed like a good investment. We also considered that we wanted a solution that could be adopted immediately. PHP 6 being a major release would require more testing before deployment and likely also to have a few bugs. (No disrespect to the developers. It's a rule of thumb.)
The extension is near done, requires much less testing and as it is compatible with 5.2 is going to be very easy for people to test and deploy.
The tradeoff made sense.
When it comes down to it, we spent a few man-months and have a 5.2 solution and can deploy in 2008.
The same few manmonths on 6 would not give a deployed solution in 2008, if for no other reason then the effort it will take to test a major release, but also because (I expected) php 6 would not be ready in 2008.
==============
Lester asks also:
MessageFormatter simply duplicates and complicates a simple display of a message with embedded variables. If I ask for to output a string with variables in using a different locale then the DATE variables should simple display the correct format for that locale. I should not have to go through all the code and re-write the variables in some complex format so another package can then do the same job that the core system IS ALREADY DOING?
Collator is already required to process strtoupper and strtolower, so why should we need to decide if we can use them or we need to create a new object and get that to do the job.
Tex replies:
I am not clear on what you are asking. It is expected that the string with embedded values is not substituted by a developer but by translators.
So for example, you could store the english string in a database table with a field for language and a field for the string and another field to identify the string.
A program could choose to retrieve a string by id and language and the string would be used with the formatter and program variables, to display the values correctly formatted for the locale in an appropriately translated string.
With respect to dates, there are simple and more complex forms. You can use the simple format. Also, note that even in one locale, you may want to influnce whether the date is a verbose long format or a shorter form. So the formatter offers options. The doc makes it seem very complex, but in practice it shouldn't be bad.
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
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 a year ago (earlier when I started lobbying Yahoo for resources for it) I naively imagined the project would be a few months. As PHP 6 was more than a year away and I suspected it would drift further into the future, it seemed like a good investment. We also considered that we wanted a solution that could be adopted immediately. PHP 6 being a major release would require more testing before deployment and likely also to have a few bugs. (No disrespect to the developers. It's a rule of thumb.)
The extension is near done, requires much less testing and as it is compatible with 5.2 is going to be very easy for people to test and deploy.
The tradeoff made sense.When it comes down to it, we spent a few man-months and have a 5.2 solution and can deploy in 2008.
The same few manmonths on 6 would not give a deployed solution in 2008, if for no other reason then the effort it will take to test a major release, but also because (I expected) php 6 would not be ready in 2008.==============
Lester asks also:MessageFormatter simply duplicates and complicates a simple display of a message with embedded variables. If I ask for to output a string with variables in using a different locale then the DATE variables should simple display the correct format for that locale. I should not have to go through all the code and re-write the variables in some complex format so another package can then do the same job that the core system IS ALREADY DOING?
Collator is already required to process strtoupper and strtolower, so why should we need to decide if we can use them or we need to create a new object and get that to do the job.
Tex replies:
I am not clear on what you are asking. It is expected that the string with embedded values is not substituted by a developer but by translators.
So for example, you could store the english string in a database table with a field for language and a field for the string and another field to identify the string.
A program could choose to retrieve a string by id and language and the string would be used with the formatter and program variables, to display the values correctly formatted for the locale in an appropriately translated string.With respect to dates, there are simple and more complex forms. You can use the simple format. Also, note that even in one locale, you may want to influnce whether the date is a verbose long format or a shorter form. So the formatter offers options. The doc makes it seem very complex, but in practice it shouldn't be bad.
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
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://www.netmeister.org/news/learn2quote.html has some good information on this topic.
regards,
Derick
Derick, Please state what you object to. I looked at the article.
I attributed the text, I responded inline, I clipped the text to the piece I was responding to, blank line in between.
I could have used a > instead of a colon in the attribution... And perhaps a signal that I clipped.
Is that what bothers you?
The questions and answers look straightforward to me.
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 a year ago (earlier when I started
lobbying Yahoo for resources for it) I naively imagined the project
would be a few months. As PHP 6 was more than a year away and I
suspected it would drift further into the future, it seemed like a
good investment. We also considered that we wanted a solution that
could be adopted immediately. PHP 6 being a major release would
require more testing before deployment and likely also to have a few
bugs. (No disrespect to the developers. It's a rule of thumb.)The extension is near done, requires much less testing and as it is compatible with 5.2 is going to be very easy for people to test and deploy.
The tradeoff made sense.When it comes down to it, we spent a few man-months and have a 5.2 solution and can deploy in 2008.
The same few manmonths on 6 would not give a deployed solution in 2008, if for no other reason then the effort it will take to test a major release, but also because (I expected) php 6 would not be ready in 2008.==============
Lester asks also:MessageFormatter simply duplicates and complicates a simple display of a message with embedded variables. If I ask for to output a string with variables in using a different locale then the DATE variables should simple display the correct format for that locale. I should not have to go through all the code and re-write the variables in some complex format so another package can then do the same job that the core system IS ALREADY DOING?
Collator is already required to process strtoupper and strtolower, so why should we need to decide if we can use them or we need to create a new object and get that to do the job.
Tex replies:
I am not clear on what you are asking. It is expected that the string with embedded values is not substituted by a developer but by translators.
So for example, you could store the english string in a database table with a field for language and a field for the string and another field to identify the string.
A program could choose to retrieve a string by id and language and the string would be used with the formatter and program variables, to display the values correctly formatted for the locale in an appropriately translated string.With respect to dates, there are simple and more complex forms. You can use the simple format. Also, note that even in one locale, you may want to influnce whether the date is a verbose long format or a shorter form. So the formatter offers options. The doc makes it seem very complex, but in practice it shouldn't be bad.
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
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 reason being, as I
said, that it is needed by people in 5.x timeframe, not 6.x timeframe.
MessageFormatter simply duplicates and complicates a simple display of a
message with embedded variables. If I ask for to output a string with
No it doesn't. It supports ICU functionality in with message formatting
(BTW backed by a number of ICU tools).
Collator is already required to process strtoupper and strtolower, so
why should we need to decide if we can use them or we need to create a
new object and get that to do the job.
For PHP 6 Collator will be integrated with the rest of core
functionality. And BTW, you don't need collator for strtoupper, you need
it for sort. Collation and case conversion/folding is not the same.
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 when you are ready to start and I'll
describe the tasks for you.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stan,
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 when you are ready to start and I'll describe the
tasks for you.
A small reply to this post (I'm still testing intl and writing my
feedback reply), more specifically to this answer.
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 resources" and to get contributions from the PHP community
directly.
Another question is still not answered, I read a couple of times "we
decided" or similar answers. As it is obvious that things have to be
decided, I did not find any public reference about any kind of
discussions so I suppose that it was done off list or in your private
list. Secondly I find amazing to reject requests because you already
decided the right way to do it. If it is so, why do you ask for our
opinions?
Cheers,
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 resources" and to get contributions from the PHP community
directly.
It's a good idea, but I want to deal with this release first. I will do
it, but a bit later.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 resources" and to get contributions from the PHP community
directly.It's a good idea, but I want to deal with this release first. I will do it,
but a bit later.
I really have hard time to understand the "everything after 1.0.0".
That makes little sense to me. As I can understand the commercial
needs behind it, I can't think of going stable while there is still
issues to be solved prior this kind a release. Especially as BC won't
be broken afterwards.
It is also amazing to systematically ignore my comments about your off
list discussions (same in Andi's reply).
Cheers.
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Friday, April 04, 2008 12:33 PM
To: Stas Malyshev
Cc: Lester Caine; PHP internals
Subject: Re: [PHP-DEV] intl namingIt 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 from April 1st.
I'm hopping on a plane in a few hours and will be gone for most of the
next two weeks. Will be catching up on emails but not as regularly as
when I'm at work. I don't think we have to rehash the same things over
and over again (jump (not that I was in favor but I don't think we
should rehash it either), ext/intl in PHP 5.3, etc...). ext/intl
specifically has been around for quite a lot of time including
"documentation" (which many extension authors actually typically ignore
to begin with making it hard for the community to give feedback), etc...
As I said in my previous email ext/intl is mainly wrappers around ICU.
We don't need to boil the ocean. If there are naming concerns then let's
change those and move on...
Andi
Hi Stan, Andi and al!
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Friday, April 04, 2008 12:33 PM
To: Stas Malyshev
Cc: Lester Caine; PHP internalsSubject: 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 from April 1st.
does that count? =)
More seriously, it does not matter if you were in favor of this
private list or not, you should have refused it. But that's my
personal opinion and I agree with you, point made.
Now about ICU, I like its simplicity. There is a clear attempt to keep
the API readable and understable by the common users. Thanks for that!
I run some tests today based on my initial thoughts (which were based
only on the documentations). I even tried with a small application
here. I try to stay as constructive as possible in my comments,
suggestions or remarks. However, I know that my English or my tone may
give the impression that I try to impose my choice, that's not the
case :) please try to keep that in mind while reading.
I also apologize for the long text, I tried to keep it concise (and failed).
The numbering is only about helping possible replies or discussions.
They do not reflect any kind of priority or preferences.
-
Procedural API is somehow useless. It duplicates the complete API
without adding any gain. -
Multiple ways to create intl instances, I'm not sure we need both
the factory and the constructor. It does not help the user to achieve
his goal but create more possible confusions (and cause of errors/
bugs). What was the idea behind ::create (if "new" has to be
supported) -
too many repetitive arguements, especially the locale.
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().The argument order for the constructors/factories should be change to
allow that. The locale argument has to be optional (and moved as 2nd+
argument).Arguments order may be confusing and hard to remember. However their
names are self explaining as long as one is familiar with the ICU
terminology. It would rock to allow array (key/pair) as
input instead of many arguments. -
Support of Date Object, they are the standard DateTime type in PHP.
It has to be done prior 1.0.0 and 5.3.0, date and time are the most
painful data to deal with in PHP. If intl and ext/date works hand in
hand it will give PHP a big kick in the date/time.The advantages are obvious and many arguments and options can be
taken from a given instance (timezone for example). -
Error management is rather unintuitive. I can't imagine to have to
check the error code after each call. Exceptions can greatly improve
it.try {
$fmt = new NumberFormatter( 'fr_CH', ....);
echo $fmt->parse($num);
$mydate = new DateFormatter( "fr_FR" , ...);
$mydate->format($ts);
} catch (Exception $e) {
....
}I can't imagine the mess if I start to use the result of a method as
arguments for other intl calls. -
What's about a __toString implementation when possible. It may be
handy to use an instance in the views (templates or whatever one
uses as views) (). It can be done for all
three formatters (number, message and date) classes.Prepare:
$invoice_line_amount = new NumberFormatter( 'fr_CH',
NumberFormatter::DECIMAL );
$invoice_line_amount->setValue($res);View:
echo $invoice_line_amount;
Locale specific:
- Being able to parse, fetch and manage Locale IDs in a consistent and
portable way would rock, the ISO3 related API is a must have prior
1.0. It can be used from day #1 to normalize locale IDs format.
cheers,
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. http://docs.php.net/manual/en/class.locale.php
The argument order for the constructors/factories should be change to
allow that. The locale argument has to be optional (and moved as 2nd+
argument).
I'm afraid that wouldn't work since functions have variable number of
arguments and we want consistent API across all modules.
Arguments order may be confusing and hard to remember. However their
Like "locale goes first"?
- Support of Date Object, they are the standard DateTime type in PHP.
Planned to be done later - if anybody wants to contribute now, please
do. It is indeed very important, we just don't have somebody to do it
right now.
- Error management is rather unintuitive. I can't imagine to have to
check the error code after each call. Exceptions can greatly improve
Like 99% people do with 99% functions in PHP? You must be really
suffering not writing code in Java :)
- What's about a __toString implementation when possible. It may be
If you can propose good toString - and especially if you have volunteer
to implement it :) - why not? We didn't have good use for toString, but
if you find one - welcome.
Prepare:
$invoice_line_amount = new NumberFormatter( 'fr_CH',
NumberFormatter::DECIMAL );
$invoice_line_amount->setValue($res);View:
echo $invoice_line_amount;
We didn't purport to implement yet another MVC templating system here.
We wrote ICU wrapper.
Locale specific:
- Being able to parse, fetch and manage Locale IDs in a consistent and
portable way would rock, the ISO3 related API is a must have prior
1.0. It can be used from day #1 to normalize locale IDs format.
Could you elaborate? I think our functions understand locales in
standard formats, but maybe you mean something else.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stan,
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. http://docs.php.net/manual/en/class.locale.php
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)?
The argument order for the constructors/factories should be change to
allow that. The locale argument has to be optional (and moved as 2nd+
argument).I'm afraid that wouldn't work since functions have variable number of
arguments and we want consistent API across all modules.
That's why I would prefer an array (as named arguments). The keys
(names) are easy to remember. You can even support both. I'm ready to
provide a patch to support array as input (with default values
support) if we agree on that.
Arguments order may be confusing and hard to remember. However their
Like "locale goes first"?
The locale as 1st argument always looked weird to me when I was
writing my test code. The reason is certainly because of the default
locale not being set or used. As it is possible (if I understand you
correctly) I don't see why it has to be as first argument, one will
always has to pass it (NULL/"" or a valid locale id).
- Support of Date Object, they are the standard DateTime type in PHP.
Planned to be done later - if anybody wants to contribute now, please do.
It is indeed very important, we just don't have somebody to do it right now.
If right now is not within days but within 2 weeks, I can try to do
it. But I first like to hear Derick's idea on the topic before. Please
let us know your thoughts (wiki?) about this topic, it will certainly
spare us some precious time.
- Error management is rather unintuitive. I can't imagine to have to
check the error code after each call. Exceptions can greatly improveLike 99% people do with 99% functions in PHP? You must be really suffering
not writing code in Java :)
Where did you get these numbers? For what I see nowadays, it is more a
high percentage with OO for everything but some basic helpers.
However, the point is not about OO or not OO but to do not duplicate
the API without any gain. Locale::foo() is as easy to write or read
than locale_foo().
- What's about a __toString implementation when possible. It may be
If you can propose good toString - and especially if you have volunteer to
implement it :) - why not? We didn't have good use for toString, but if you
find one - welcome.
I will think about it a bit more. But that will rock to have it :)
Prepare:
$invoice_line_amount = new NumberFormatter( 'fr_CH',
NumberFormatter::DECIMAL );
$invoice_line_amount->setValue($res);View:
echo $invoice_line_amount;We didn't purport to implement yet another MVC templating system here. We
wrote ICU wrapper.
I was not clear, sorry. The goal is not to create a MVC but to allow
easy and user friendly usage without having to use intermediate string
variable or other custom objects.
Locale specific:
- Being able to parse, fetch and manage Locale IDs in a consistent and
portable way would rock, the ISO3 related API is a must have prior
1.0. It can be used from day #1 to normalize locale IDs format.Could you elaborate? I think our functions understand locales in standard
formats, but maybe you mean something else.
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.).
Cheers,
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
We aimed to create a wrapper for ICU, not reinvent how PHP language
works. So we accept arguments the usual way - through function
parameters, not through arrays.
The locale as 1st argument always looked weird to me when I was
writing my test code. The reason is certainly because of the default
I guess that's a matter of personal taste.
If right now is not within days but within 2 weeks, I can try to do
it. But I first like to hear Derick's idea on the topic before. Please
let us know your thoughts (wiki?) about this topic, it will certainly
spare us some precious time.
Well, the thoughts here are pretty simple - where date formatting
functions accept timestamp and localtime array, they should accept
DateTime object too. Also, there should be parse function returning
DateTime, like one that returns timestamp. I think if you look in CVS in
doc folder, early versions of date formatter API mention that.
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 mean create API translating from language name in given locale to
language code? I'm not sure ICU has this API. Locale class allows you to
get components and display strings for the locales, but you have to have
locale IDs first. There also are some matching functions in Locale, but
I don't see any ICU functions allowing you to know IDs from external
information, only to choose from set of IDs and enquire about ID.
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.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
Damned, I missed it four times :) It is not present in the synopsis
but in the methods list.
Then I really don't understand the current methods signature. The
locale should be optional and obivously not as first argument.
That's why I would prefer an array (as named arguments). The keys
We aimed to create a wrapper for ICU, not reinvent how PHP language works.
So we accept arguments the usual way - through function parameters, not
through arrays.
You may aim to create a thin wrapper around ICU, but we aim to create
the best possible i18n API. :-)
There is many API using this method when there is too many arguments,
when the risk of confusions is high.
About creating a wrapper, that's actually part of the solution to do
not create a thin wrapper but to add some "intelligence" in the
extension to ease its usage. It is even more important for APIs like
what intl try to do as it will be used by almost everyone out there.
The locale as 1st argument always looked weird to me when I was
writing my test code. The reason is certainly because of the defaultI guess that's a matter of personal taste.
No, that's a matter of being able to use a default locale without
passing NULL or an empty string. That's really bad practice to have an
optional argument as first argument.
If right now is not within days but within 2 weeks, I can try to do
it. But I first like to hear Derick's idea on the topic before. Please
let us know your thoughts (wiki?) about this topic, it will certainly
spare us some precious time.Well, the thoughts here are pretty simple - where date formatting functions
accept timestamp and localtime array, they should accept DateTime object
too. Also, there should be parse function returning DateTime, like one that
returns timestamp. I think if you look in CVS in doc folder, early versions
of date formatter API mention that.
Thanks for the hint, I will take a look at the history.
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 mean create API translating from language name in given locale to
language code? I'm not sure ICU has this API. Locale class allows you to get
components and display strings for the locales, but you have to have locale
IDs first. There also are some matching functions in Locale, but I don't see
any ICU functions allowing you to know IDs from external information, only
to choose from set of IDs and enquire about ID.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.
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 provide a list and then a patch.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
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.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 provide a list and then a patch.
I think locale validity detection does not work in PHP6
locale_set_default() too. Bug 42471.
--
Tomas
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 provide a list and then a patch.
You have getRegion, but it looks like no ISO ones now.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
re,
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 areWhat is "valid"? Database can have no exact match for locale string, but
still have some data from fallbacks, etc.getCountry, getISO3* etc. I can provide a list and then a patch.
You have getRegion, but it looks like no ISO ones now.
The current one is somehow limited given what ICU provides. I know
that locale string are evil but it is the exact reason why we should
help our developers to use some more standard one, whenever it is
possible. Having the previously cited functions as well as getISO*,
getAvailableLocale, etc. will help.
Will you agree to extend the Locale API to provide more informations?
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 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).
David
Am 08.04.2008 um 22:04 schrieb Stanislav Malyshev:
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 course.
Wearing my 'editor/educator' hat, can I just point out that we're still
teaching long-time PHP users from all over the planet what exceptions even
are?
Can I also point out that every uncaught exception is a fatal error?
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.
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.
- Steph
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 dirty prototype.
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
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 the ability of our users to
learn, but that's the least problem here. The main problem with the
error code ways, using a return value or via extra function calls, is
that they are never used or checked. Even the examples in the manual
never use them. That's promoting bad practices and then users will
wonder why their string look broken or empty.
Can I also point out that every uncaught exception is a fatal error?
My example was not about not catching exceptions but about actually
catch the possible exception. As I agree that exception can be
confusing, their usage is this particular case is not that hard.
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.
Look at the syntax, there is no difference. One doesn't need to be a
computer scientist to understand it.
If we decide to keep the procedural API then let use a normal (and CS
compliant .. well almost compliant) prefix. Using shorter names to
spare a few key strokes is not a very good idea. number_format _ is
better than numberfmt_.
Cheers,
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 mean create API translating from language name in given locale to
language code? I'm not sure ICU has this API. Locale class allows
you to get
components and display strings for the locales, but you have to
have locale
IDs first. There also are some matching functions in Locale, but I
don't see
any ICU functions allowing you to know IDs from external
information, only
to choose from set of IDs and enquire about ID.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.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 provide a list and then a patch.
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, it isn't in most cases; you know
the locale IDs beforehand.
David
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 provide a list and then a patch.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, it isn't in most cases; you know the locale IDs
beforehand.
I'm willing to trust you but my experiences tell me that it is not
always available before hand and that every 2nd lib duplicate this
information (partially or completely. It has no bad side effect to
introduce some new methods for this purpose :)
Cheers,
Am 09.04.2008 um 08:48 schrieb Pierre Joye:
On Wed, Apr 9, 2008 at 12:07 AM, David Zülke dz@bitxtender.com
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, it isn't in most cases; you know the
locale IDs
beforehand.I'm willing to trust you but my experiences tell me that it is not
always available before hand and that every 2nd lib duplicate this
information (partially or completely. It has no bad side effect to
introduce some new methods for this purpose :)
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 instance.
Be advised that attempting to map, for instance, a country code to a
locale is futile anyway. You can't map "ch" to anything. There's
de_CH, fr_CH and it_CH locales to choose from. Locales and country/
language/blah codes really are differnt things, and I've never needed
automated mappings so far (usually, the locale code itself is more
than enough).
David
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 instance.Be advised that attempting to map, for instance, a country code to a locale
is futile anyway. You can't map "ch" to anything. There's de_CH, fr_CH and
it_CH locales to choose from. Locales and country/language/blah codes really
are differnt things, and I've never needed automated mappings so far
(usually, the locale code itself is more than enough).
Thanks for the advice :) However I already know that and to use
incomplete code as a mapping key (or whatever else) is not the goal (I
don't think I ever mentioned this idea).
To have the ISO lists, the list of available locales (to be
interpreted carefully), or do some basic operations on the locales is
what I like to have. The ICU Locale API is very complete, it can be
misused (there is many things that can be mishandled in PHP), why
should we not have it in PHP?
Cheers,
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 there any chance this is not going to be available for 5.2?
Because if so, I would add another option to the naming suggestions below:
- finally use namespaces
Although I'm next to not at all involved in the current development, this was
actually on my mind for a view days and I was thinking about writing to the list.
Especially with so many classes at once introduced I think it would be a good
idea to finally think about this too.
Personally, globbering the global namespace with such common names is
irresponsible (but this has been discovered already).
Actually there are existing classes being named Locale, I fired a quick google
code search:
http://www.google.com/codesearch?q=lang%3Aphp+class.*Locale&hl=en&btnG=Search+Code
Of course I've never heard of them myself, but it's really not hard to assume
that such a class likely exists.
The same applies to the "Collator" class, see
http://www.google.com/codesearch?hl=en&lr=&q=lang%3Aphp+class.*Collator&btnG=Search
More example could probably be found but I think the two examples makes it
clear that we need to namespace or prefix them. Of course I've never heard of
and used any of those classes and I guess most internal developers here
probably have neither, but that doesn't mean they aren't in use somewhere.
I understand that, as long as this has to be available for 5.2, namespaces are
forever out because of BC. But if this could be pushed, I would really be happy.
Just to be clear, this is not some kind of bickering and especially not about
ext/intl, but I'm trying to create a general awareness of problems we would
run here in the future.
If namespaces aren't and option because waiting for 5.3 only is not viable,
I'm for number four. Stop creating headaches with namespace/prefix-less
introduction of new things.
- Rename both classes and functions.
Pro: All API looks the same, purists are happy
Contra: API looks ugly, too many prefixes for functions.
thanks,
- Markus
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 naming suggestions below:
- finally use namespaces
I'd love it, but unfortunately - see above.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 it would not missed if omitted - have you had
any specific requests for it?
On the API side have you considered throwing exceptions instead of
checking error statuses? Also would it not be useful to have the
DateFormatter optionally accept DateTime instances in addition to
strings?
Thanks,
John.
-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: 03 April 2008 05:58
To: 'PHP Internals'
Subject: [PHP-DEV] intl naming
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
First, a bit of background.
Intl extension project was created with the purpose to bring
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
more enterprise adoption, it needs to start supporting internationalized
development much sooner than PHP 6 roadmap would allow us to. Thus, the
goals of the project were chosen as follows:
- Provide dual OO/procedural API for all functions 2. Provide same PHP
API for both PHP 5 and PHP 6, to allow easy migration in the future 3.
Keep same codebase in 5.x versions and keep codebases between 5 and 6 as
close as possible 4. Have separate functional modules for each
functionality piece (number formatter, locale handling, collator,
normalization, etc.) with intend to add more modules as we go, while
keeping single extension as an umbrella for them.
As a consequence, we arrived at the naming scheme we have now in
pecl/intl, i.e. classes named as NumberFormatter, MessageFormatter,
DateFormatter, Collator, etc. and functions named as numfmt_, msgfmt_,
collator_, datefmt_. The latter were chosed in accordance to the
guidelines stated at http://www.php.net/reST/php-src/CODING_STANDARDS,
saying:
If they [function names - SM] are part of a "parent set" of functions,
that parent should be included in the user function name, and should be
clearly related to the parent program or function family. This should be
in the form of parent_*.
Recently, concerns were raised specifically about the name
DateFormatter, which can potentially infringe on ext/date namespace, and
in general about all the names. There were proposals to prefix all class
and function names with Intl and intl_ respectively. While I feel that
would make the API unnecessarily cluttered (since each module will have
to keep its prefix anyway, we'd have stuff like
intl_numfmt_parse_currency which IMO looks much uglier than
numfmt_parse_currency, same goes for IntlCollator vs. Collator, etc.)
However, technically it is possible to do such change, and I believe if
it has to be done it has to be done now, when we have first phase of the
development feature-complete and ready (up to bugfixes here and there)
to announce the module as 1.0 version for everybody to use.
So, I propose people to consider all the above and the following
options:
-
Leave it as is.
Pro: we have it now and it works, and it looks nice.
Contra: see above -
Rename only problematic one - DateFormatter to IntlDateFormatter
Pro: minimal change, nice names stay and can be used in PHP 6 API too.
Contra: one piece starts with Intl, others don't - API looks weird as a
whole -
Rename all classes to Intl* while leaving functions as is
Pro: All classes in the extension look the same, functions still have
nice names
Contra: All classes get ugly names, and they are going to stay in PHP 6
where those will be recommended system classes (so not Locale but
IntlLocale, not Collator but IntlCollator). -
Rename both classes and functions.
Pro: All API looks the same, purists are happy
Contra: API looks ugly, too many prefixes for functions.
So, please comment. If you have more ideas on the topic, please feel
welcome to propose. We want to make this decision ASAP, so that we could
move forward with the extension release.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
--
To unsubscribe,
visit: http://www.php.net/unsub.php
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
dz@bitxtender.com
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ünchen
Am 03.04.2008 um 06:58 schrieb Stanislav Malyshev:
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.phpFirst, a bit of background.
Intl extension project was created with the purpose to bring
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 more enterprise adoption, it needs to start supporting
internationalized development much sooner than PHP 6 roadmap would
allow us to. Thus, the goals of the project were chosen as follows:
- Provide dual OO/procedural API for all functions
- Provide same PHP API for both PHP 5 and PHP 6, to allow easy
migration in the future- Keep same codebase in 5.x versions and keep codebases between 5
and 6 as close as possible- Have separate functional modules for each functionality piece
(number formatter, locale handling, collator, normalization, etc.)
with intend to add more modules as we go, while keeping single
extension as an umbrella for them.As a consequence, we arrived at the naming scheme we have now in
pecl/intl, i.e. classes named as NumberFormatter, MessageFormatter,
DateFormatter, Collator, etc. and functions named as numfmt_,
msgfmt_, collator_, datefmt_. The latter were chosed in
accordance to the guidelines stated at http://www.php.net/reST/php-src/CODING_STANDARDS
, saying:If they [function names - SM] are part of a "parent set" of
functions, that parent should be included in the user function name,
and should be clearly related to the parent program or function
family. This should be in the form of parent_*.Recently, concerns were raised specifically about the name
DateFormatter, which can potentially infringe on ext/date namespace,
and in general about all the names. There were proposals to prefix
all class and function names with Intl and intl_ respectively. While
I feel that would make the API unnecessarily cluttered (since each
module will have to keep its prefix anyway, we'd have stuff like
intl_numfmt_parse_currency which IMO looks much uglier than
numfmt_parse_currency, same goes for IntlCollator vs. Collator, etc.)
However, technically it is possible to do such change, and I believe
if it has to be done it has to be done now, when we have first phase
of the development feature-complete and ready (up to bugfixes here
and there) to announce the module as 1.0 version for everybody to use.So, I propose people to consider all the above and the following
options:
Leave it as is.
Pro: we have it now and it works, and it looks nice.
Contra: see aboveRename only problematic one - DateFormatter to IntlDateFormatter
Pro: minimal change, nice names stay and can be used in PHP 6 API too.
Contra: one piece starts with Intl, others don't - API looks weird
as a wholeRename all classes to Intl* while leaving functions as is
Pro: All classes in the extension look the same, functions still
have nice names
Contra: All classes get ugly names, and they are going to stay in
PHP 6 where those will be recommended system classes (so not Locale
but IntlLocale, not Collator but IntlCollator).Rename both classes and functions.
Pro: All API looks the same, purists are happy
Contra: API looks ugly, too many prefixes for functions.So, please comment. If you have more ideas on the topic, please feel
welcome to propose. We want to make this decision ASAP, so that we
could move forward with the extension release.Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 the plan, but maybe it would be a good idea)
I'm afraid this is not an option.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
replies, of which I have two stating preferences about the options
brought up here. Besides that, I also know Derick's opinion from the
previous discussions. If anybody else has something to contribute to the
subject, please speak up.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.phpSince publishing this mail about 2 weeks ago I have received a number of
replies, of which I have two stating preferences about the options brought
up here. Besides that, I also know Derick's opinion from the previous
discussions. If anybody else has something to contribute to the subject,
please speak up.
I hope you are keeping in mind our last discussion here. I also like
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 really fear to suddenly see a 1.0.0-stable with none of our requests
inside.
Also please find a patch as attachment. It fixes a possible crash in
datefmt_create. I have some more to come but I did not get the time to
finish.
The ICU build problem remains as well. I'm not sure it is safe to use
2k3 binaries with php VC6 binaries. I wonder how you built it using
vc2005. It fails with all possible errors here. Any trick?
Cheers,
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 them
inappropriate in the context of this extension. However, my question was
not about redesigning the API, but specifically about names.
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.
Also please find a patch as attachment. It fixes a possible crash in
datefmt_create. I have some more to come but I did not get the time to
finish.
thanks, applied
The ICU build problem remains as well. I'm not sure it is safe to use
2k3 binaries with php VC6 binaries. I wonder how you built it using
vc2005. It fails with all possible errors here. Any trick?
No trick, just checked out the code, put the libs in ../icu, run
configure and nmake.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
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 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.
The ICU build problem remains as well. I'm not sure it is safe to use
2k3 binaries with php VC6 binaries. I wonder how you built it using
vc2005. It fails with all possible errors here. Any trick?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.
Cheers,
Hi,
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,
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,
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 there,
others should be too.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 there, others should be
too.
You can check the ICU version (if you know which version has what),
some were not present in my old version. I think it is safer to check
them, it eats no bread and cry when something is missing ;)
Cheers,
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 found together, so if icuuc.lib is there,
others should be too.
Number one rule - assuming anything is very bad especially where
anything windows is involved ;) "Should" usually leads to annoying
emails and bogus bugs... As Pierre said it really doesn't hurt anything
to check for them all.
Elizabeth
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com