> 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