Feature request: constructor with the amount in pennies

[DrHyde]

It would be useful to be able to create a Data::Money object, passing the value in pennies, and for Data::Money to do the hard work of figuring out whether there are 100 or 1000 pennies in the currency unit. For example, the Bahrain Dinar consists 1000 fils, so code that accepts an amount in pennies from elsewhere and naively assumes it can just divide by 100 to get a suitable value is incorrect.

[DrHyde]

The new constructor should also cope with currencies which don't have sub-units such as JPY

[duffee]

The rationale for this feature is that the payments company, Stripe, works in sub-units of the currency which presents interesting edge cases for the currencies where 100 sub-units != unit (such as JPY, ISK, KRW, CLP and a handful of others)

[manwar]

@duffee @DrHyde I need some clarity here?

1. Should the constructor handle negative amounts or fractions of a sub-unit?
2. What should happen if the provided amount in sub-units doesn't divide evenly by the currency's subunit count? (e.g., providing 101 fils for a BHD object - should it round, store as fraction, or throw an error?)
3. Should the method be named something more generic like new_from_smallest_unit?

[duffee]

oooh, it's been a while ;) and neither of us are on that project anymore.

My 2 pennies:

1.

You could consider money like DateTimes, where you don't usually have negative money, but do have maths. OTOH, if you create a negative Money, you are calling it a credit/debit from the start so you don't have to remember the sense of the object later and you can do this
$bill += $_ for @prices;
instead of
$bill += $_ for @prices; $bill -= $_ for @discounts;

I'm less inclined towards fractions of a sub-unit. Some bankers might be interested (ask Lee Johnson from his LPW talk on Banking), but part of me worries about the difficulties presented with overflow errors on floats adding up to create an issue where equality becomes hard to test. Oh, but I see you're using BigInt/Float so that shouldn't be a problem. Do what you think is right.

2.

I'm not clear on how this problem presents. I'll need a couple of examples for the ... penny to drop. (sorry/not sorry)

3.

Probably. A new name (even new_from_subunit) is probably more clear than having a value_in_subunits => 1 flag in the object constructor