> well it's not prevented from being expressed; it's just expressed using a
> Quantity field (e.g. a DV_COUNT) and another field saying what you are
> counting (there are a reasonable number of examples of this already in the
> archetypes - number of cigarettes a day, number of previous pregnancies,
> number of steps taken in physiotherapy etc). If we made this a Quantity, we
> could in theory then use an instance to say '3 puffs'. But this is not an
> amount of substance, it's a count of 'delivery' units or 'grains' of
> substance. I still think Quantities should be computable as such - if we
> don't know how many mcg of substance 3 puffs is, we can't compute with it.

ok, so you say it should be computable, but then allow a fixed unit of one,
and some other code as well. And this in a subclass of Quantity, so you
could always use it or encounter it in place of quantity. So if that's the
case, why not simply make it a property of Quantity? What's really
important is not that all Quantities are computable, but that you know
whether you can compute with it. And in fact, making it a property of
Quantity makes it easier to manage and/or constrain

Grahame

Reply via email to