Symbol is bad identificator

[martianoff]

We should think about it but it seems symbols are not always good as unique unit ID, for example "mpg" can be mpg UK and mpg US which are different, right now it seems we have no way to add support of these measurements:

L/100 km	MPG (UK)	MPG (US)
1	282.48	235.21
2	141.24	117.61
3	94.16	78.40

[jordanbrauer]

For sure this is a shortcoming with the implementation of this package.

The original design of the component was to accept strings as SI unit symbols (or whatever you configure the symbols as) as input so that you could process arbitrary text data from large spreadsheets containing measurements (e.g., product dimensions for shipping cost estimates).

---

I will try and think of a solution and whip something together ASAP. One idea that I have been toying with, is adding a new concept of "variations" to units. The registry key could be extended by 1 level to specify which variation

E.g.,

Keeping with your example of UK and US mpg, the registry key(s) would be:

'volume.mpg'; # current registry key would remain as a fallback to default "variation"
'volume.mpg.us'; 
'volume.mpg.uk';

The variation (uk, us) would be passed in as parameter to the converter, or to the unit in constructor.

$mpgUs = new MilesPerGallon(1, 'us');
$mpgUk = new MilesPerGallon(1, 'uk');

$mpgUs->as($mpgUk); # 1.201
$converter->convert(1)->from('mpg', 'us')->to('mpg', 'uk'); # 1.201

Stay tuned!

[jordanbrauer]

This has some development started on it – follow #145 if you're intereseted @maksimru