NB: I am replying after reading the paper thanks to non-public  
transmission, although as a practitioner's paper it mostly says the  
same as in cited papers, e.g. "Object-Oriented Units of Measurement".

NB: I am persistent with questions because I enjoy making a good  
design, not because I am critical.

On Mar 28, 2006, at 3:40 AM, hernan_wilkinson wrote:

> --- In squeak at yahoogroups.com, Brian Rice <water at ...> wrote:
>> A lot of the extra work appears to be a huge unit-test suite, which
>> is good. There is also some kind of graph model and some evaluation/
>> thunking mini-library.
>
> Yeah, the graph model (very simple one) is to convert measures from
> different "domains". This is usefull when you have financial measures
> like "10 * dollar" and want to convert that to Euros. In this case the
> conversion is not fixed (like in all physical measures) and depends on
>   different forces, like the financial market, date-time, etc.

However, the graph model is not needed unless a conversion from A to  
B to C is not transitive. That is, if I had ((A convertedTo: B)  
convertedTo: C) and wanted it to be different than (A convertedTo:  
C), then the graph model would be useful, but otherwise you can just  
use double-dispatch and have those methods consult whatever exchange- 
rate service exists.

Specifically, you could have a convertTo: method just for financial  
measurements which did this generically for all financial conversions.

How does the graph model add to this? Does it give some extra  
statefulness or persistence? Do you have time-outs for financial  
conversion amounts? Why not put those timeouts or statefulness/ 
persistence in a CurrencyExchange class/service?

>> 3) I like the MeasureBag idea. Does it work for non-Integer values
>> and why or why not?
>
> What do you mean with non-Integer values?. Let me give you some  
> examples:
> (20 * dollar) + (10 * euro) --> Returns a measure bag with 20 dollars
> and 10 euros
> (20 * dollar) + 1 --> Returns a measure bag with 20 dollars and the
> number 1
> (20 * apple) + (5 * orange) --> Returns a bag with 20 apples and 5  
> oranges
>
> Again, this is useful for financial measures. It does not make sense
> for example with physical measures.
>
>>
>> 4) "Measure" suggests measurement, which has precision and tolerance.
>
> We have struggle with the name for a while. We don't use measurement
> (althoug we used to use it) because it suggests an action (a verb).
> We use Measure becuase it is a noum.
> We almost call it Quantity, but the name does not comunicate well...
> Because it is not a measurement, it does not have a precision and
> tolerance.
>
>> Do you take these into consideration? If not, why name it Measure
>> instead of DimensionedUnit or something? It will be confusing if
>> someone makes a separate type system that /does/ handle precision and
>> tolerance.
>
> I'm not sure DimensionedUnit is a better name, becuase it puts the
> attention on the unit but we want to put it on the measures...

Well, I can accept that. Why don't we reconsider it as  
DimensionedNumber or DimensionedValue, then?

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060328/c3ff3c5c/PGP.pgp