--- In squeak at yahoogroups.com, Brian Rice <water at ...> wrote:
>
> 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".
> 
In some sense, it sure it does because it an old topic, it is not new,
that's why we wrote a practitioner report.
Although, there are some differences with the classic approach, that
is usually "static" (Object Oriented Units of Measurement proposes to
use type checking to verify unit conficts) and our approach is more
"dynamic". 
It also have some clues on how we use it on the financial domain, that
for people that work on that domain I think they are new ideas...
(represent residual quantities of bonds with measure, prices with
measures, etc.)

> NB: I am persistent with questions because I enjoy making a good  
> design, not because I am critical.
No problem, I like to have critics!

> 
> On Mar 28, 2006, at 3:40 AM, hernan_wilkinson wrote:
> 
> > --- In squeak at yahoogroups.com, Brian Rice <water@> 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.

The graph is use when you need transitive conversions as you say. This
kind of transitive convertions "can be" common on the financial
domain. For example, you have the relation from dollar to euro, from
euro to peso, but want to convert from dollar to peso. 
With the graph we also handle the situation where converting from
dollar to euro is not the same as converting from euro to dollar.
For the rest of the conversions (conversions on measures of the same
domain, for example meter to centimeter, days to hours, etc), we just
use double dispacth as you say.

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

I guess I answered this on the previous paragraph

> 
> 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?

The graph model has nothing to do with persistence. Our application
uses GemStone so we get persistence from it. The same with time outs,
it is not related.
We do have an object that takes care about money conversion,
instruments valuations, etc. But those are higher level layers of
abstraction. 
This package is simple and it is not tied to any kind of measure,
that's why we can use it in the financial domain, time domain, etc. 
We solved the problems you are talking about but in higher layers...

> 
> >> 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.

In some sense your are rigth and that is what I said in the FAQ.
But if we think a little bit about things you can express in reality,
you could say "I have 1 liter of milk and 3 pices of cake". How do you
represent that if you don't allow to mix liters with pices?
Againg, this model has no restrinction on the things you can do with
measures, if you want to be sure that meters and seconds don't get
added, you need a higher level of abstraction to represent that. See
the concept of Evaluation that is useful for this.
> >
> >>
> >> 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).

I made a mistake here, Measurement is not an action but the result of
it (to take a measure, in Spanish it would be "Medicion").
On the other hand, Measure has a broader meaning and it is not tied
with the action of taking a measure (in Spanish it would be "Medida").

> > 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?

Well, let us thing about it...

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