alcohol / iso3166

A PHP library providing ISO 3166-1 data.
https://iso3166.thephpleague.com
MIT License
640 stars 59 forks source link

based on #14 largely #18

Closed alcohol closed 7 years ago

alcohol commented 8 years ago

hopefully a decent compromise between requested/suggested changes and project goals

this resolves #7, closes #14

nyamsprod commented 8 years ago

I see that you are not validating the name and/or the currency index ? Does it mean that they are optional ?

alcohol commented 8 years ago

Yes I intentionally left those out, as I think this makes it easier for others to substitute them in whatever shape or form they would like to (nested object, multidimensional array, etc). As long as the lookup can be guaranteed to work through the presence of keys, we are OK I think.

alcohol commented 8 years ago

@nyamsprod I think this PR addresses most of your concerns in its current form now?

nyamsprod commented 8 years ago

One last remark about the guardAgainstInvalid* methods.

In my original proposal I had methods called validate* which were badly name but did 2 things

A better name would have been filterAlpha2. The usage was as follow

$input = $this->filterAlpha2($input);
//triggers exception on failure
//return normalized key on success

The benefice of this was that you could in the class ISO3166 directly make a === comparison. With the current guardAgainstInvalid* methods. No normalization is done. So

$collection->getAlpha2('fr');
$collection->getAlpha2('FR');

won't give the same results one will trigger an exception and it would even introduced a BC break.

Apart from that everything else is :+1: for me

frankdejonge commented 8 years ago

@nyamsprod agreed on the filterX naming proposal 👍

alcohol commented 8 years ago

The thing is that if we allow custom datasets, people might have ones with lowercase keys. Which isn't necessarily disallowed. So if we use normalization by default, those would not work. Hence why I reconsidered. Otherwise we have to make the guards more strict, which would be a BC change sort of.

nyamsprod commented 8 years ago

If you don't normalize the input $countries data then you must at least normalize the value from the getBy method

    private function getBy($key, $value)
    {
        $value = strtoupper($value);
        foreach ($this->countries as $country) {
            if ($value === strtoupper($country[$key])) {
                return $country;
            }
        }
        throw new \OutOfBoundsException(sprintf('No "%s" key found matching: %s', $key, $value));
    }

bottom line you need to normalize the input at some point otherwise you introduce a BC break. Having said that the filter* behaviour is similar to how PHP's filter_var function works. On success the function may normalize/format the input whereas on failure the function returns false.

alcohol commented 8 years ago

I think you misunderstood the point I am making. Since we do not normalize input, we should not normalize queries.

nyamsprod commented 8 years ago

mmmh so for you it is normal that

$collection->getAlpha2('fr');
$collection->getAlpha2('FR');

returns different result ? If the answer is no. Then at some point you need to normalize some data.

alcohol commented 8 years ago

I would consider that normal in some other languages :p Definitely would have my preference.

But since I was using strcasecmp before I suppose it would be a bit of a backwards compatibility break. I can just replace the === with strcasecmp again.