Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Use classes and interfaces to represent the shipped ICU data #11887

Copy link
Copy link
Closed
@bojanz

Description

@bojanz
Issue body actions

This issue discusses the new intl API that's being made in #9206.
I've opened it because I believe this discussion is outside the scope of that PR (and would probably have a very different target version).
The current code also has the same approach (API with static methods).

The ICU data ships with definitions for currencies, countries, languages and more.
However, since the API imitates ICU itself, it feels odd and less PHP-like.
Instead of returning objects with the relevant information, the central service has a static method per relevant property that returns an array.

Here's a currency example:

$currencyCode = 'EUR';
$numericCode = Currency::getNumericCode($currencyCode):
$fractionDigits = Currency::getFractionDigits()
$name = Currency::getName($currencyCode);
$symbol = Currency::getSymbol($currencyCode);

Now let's compare that to how commerceguys/intl does it:

$repository = new CurrencyRepository();
// Get the USD currency using the default locale (en).
$currency = $repository->get('USD');
echo $currency->getCurrencyCode();
echo $currency->getNumericCode();
echo $currency->getFractionDigits();
echo $currency->getName();
echo $currency->getSymbol();

In the second example we get an object implementing the CurrencyInterface.
This is important because in most ecommerce scenarios there is a need for the admin to modify existing currencies or define custom new ones, which leads to currencies being stored in the database. So, a Doctrine entity can implement the CurrencyInterface and behave just as the currency created from default definitions, as far as the rest of the system is concerned.

webmozart said:

It does not represent individual I18N objects (currencies, locales etc.) as objects - for performance > reasons. For example, if you need a list of locale names, initializing an array of hundreds of Locale > objects first adds noticeable overhead.

I'm not convinced because we already have the cost of all those arrays storing the names, symbols, fraction digits, etc. Arrays have been shown to be very expensive.
Having an array of typed objects instead provides a much cleaner API that can integrate nicely with other components and systems. If there's a performance impact, it's well worth it, but I'm prepared to do benchmarks.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.