On Fri, 19 Oct 2007 11:20:27 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality.
Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-)
Pardon my ignorance, do you have the patience to explain? but... you're putting all this responsibility on the site administrator that would specify a string to format it. You're not "mutating" one currency in another. You're just expressing a currency in the "locale" format. Maybe we should express locale in a more complex way: language + "localisation" so that English may be Canadian, UK or US... with some system to avoid content duplication Are you referring to exchange rate? That will be an issue of the application programmer. I'm not interested in an object to store currency... currency will appear magically in a variable (task of the app. programmer) and they have to be formatted accordingly to the locale (maybe a wider concept than what locale is now). Before revolutionising locale (language + "localisation specialisation") I'd just add the formatting functions. You can keep the signature of functions and just create an EnglishUK EnglishUS etc... language if you really need to deal with the difference. I'd put date/currency/whatever object out of drupal. I think it's not the task of a CMS to "understand" content unless you're obliged too. So why should you provide a currency object? -- Ivan Sergio Borgonovo http://www.webthatworks.it