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:
1. 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:
1. Leave it as is.
Pro: we have it now and it works, and it looks nice.
Contra: see above
2. 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
3. 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).
4. 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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
