Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36814
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
Message-ID: <E6363915-D00C-4F6B-BBA5-57F6934EB29B@bitxtender.com>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <47F463F0.4030407@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sat, 5 Apr 2008 16:35:57 +0200
References: <47F463F0.4030407@zend.com>
Subject: Re: [PHP-DEV] intl naming
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

What about
a) an "ICU" prefix?
b) daring the leap and use namespaces, making it 5.3+ only (I know, =20
that wasn't the plan, but maybe it would be a good idea)


David

--
David Z=FClke
dz@bitxtender.com
Tel: +49 (0)89 57 08 15 15
Fax: +49 (0)89 57 08 15 17
bitXtender GbR
Paul-Heyse-Stra=DFe 6
80336 M=FCnchen








Am 03.04.2008 um 06:58 schrieb Stanislav Malyshev:
> Hi!
>
> I wanted to ask the people here for opinions on the subject of =20
> functions naming in pecl/intl (hopefully soon to be ext/intl ;) =20
> 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 =20
> internationalization capabilities of the ICU library to PHP 5, =20
> specifically 5.2.x and 5.3.x branches. We felt that as PHP gets more =20=

> and more enterprise adoption, it needs to start supporting =20
> internationalized development much sooner than PHP 6 roadmap would =20
> 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 =20
> migration in the future
> 3. Keep same codebase in 5.x versions and keep codebases between 5 =20
> and 6 as close as possible
> 4. Have separate functional modules for each functionality piece =20
> (number formatter, locale handling, collator, normalization, etc.) =20
> with intend to add more modules as we go, while keeping single =20
> extension as an umbrella for them.
>
> As a consequence, we arrived at the naming scheme we have now in =20
> pecl/intl, i.e. classes named as NumberFormatter, MessageFormatter, =20=

> DateFormatter, Collator, etc. and functions named as numfmt_*, =20
> msgfmt_*, collator_*, datefmt_*. The latter were chosed in =20
> accordance to the guidelines stated at =
http://www.php.net/reST/php-src/CODING_STANDARDS=20
> , saying:
>
> If they [function names - SM] are part of a "parent set" of =20
> functions, that parent should be included in the user function name, =20=

> and should be clearly related to the parent program or function =20
> family. This should be in the form of parent_*.
>
> Recently, concerns were raised specifically about the name =20
> DateFormatter, which can potentially infringe on ext/date namespace, =20=

> and in general about all the names. There were proposals to prefix =20
> all class and function names with Intl and intl_ respectively. While =20=

> I feel that would make the API unnecessarily cluttered (since each =20
> module will have to keep its prefix anyway, we'd have stuff like =20
> intl_numfmt_parse_currency which IMO looks much uglier than =20
> numfmt_parse_currency, same goes for IntlCollator vs. Collator, etc.)
> However, technically it is possible to do such change, and I believe =20=

> if it has to be done it has to be done now, when we have first phase =20=

> of the development feature-complete and ready (up to bugfixes here =20
> 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 =20
> 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 =20
> 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 =20
> have nice names
> Contra: All classes get ugly names, and they are going to stay in =20
> PHP 6 where those will be recommended system classes (so not Locale =20=

> 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 =20=

> welcome to propose. We want to make this decision ASAP, so that we =20
> could move forward with the extension release.
> --=20
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>