Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!cix.compulink.co.uk!tlaw
From: tlaw@cix.compulink.co.uk ("Anthony D Law")
Subject: Re: A Money object
Message-ID: <Cxt6Mv.41y@cix.compulink.co.uk>
Organization: Parkside Information Management
References: <37is8r$6m2@news.uni-c.dk>
Date: Mon, 17 Oct 1994 08:37:42 GMT
X-News-Software: Ameol
Lines: 21

INterested in this one. Lots of problems, which makes it a winner for OO 
approach I believe.

First, as the first poster said, there are different exchange rates 
depending what you are converting /for/ (current trading, consolidated 
annual report and accounts, etc).

Second, there are some currencies where the base unit is small value 
where local legislation requires integer calculation (Belgian Franc and 
Lira for example, IIRC). As an example, BT here calculates phone bills 
using fractions of 1p in unit costs, and calculates VAT on the lot, then 
rounds the answer. This would not be allowed in Italy I believe (anyone 
from Belgium or Italy care to comment)?

The advantage, then, of a class-based approach is that you can build all 
these operations and over-ride them in subclasses, e.g. Money => 
(IntegerMoney, DecimalMoney, FunnyUnitMoney). Instances of these three 
would be Lira, US Dollar, and the old UK pounds, shillings and pence.

TOny
(Tony Law, tlaw@cix.compulink.co.uk)
