I believe that C++, for example, has everything you need to
be able to do this sort of thing in the type system. I am
not aware, however, of any body of people finding it to be
worth the effort.

Marshall

Below script models 20 ft, 20 sec, conversion from ft to meter, etc in
xrdb.
Application code (OO or not) should perform conversion based on data in
db.

// Create type distance, time, qty and unit
// and make them items of main directory.
// Note: "inst" is short for "instance".
// Note: "it" refers to last new thing created by "*" in CREATE stmt.
(CREATE type inst *distance  & dir item it)
(CREATE type inst *time      & dir item it)
(CREATE type inst *qty       & dir item it)
(CREATE type inst *unit      & dir item it)

// Create 20 ft.
(CREATE distance inst *
     & it qty +20
     & it unit +feet)

// Create 40 ft.
// Note: db auto normalized unit "feet"
(CREATE distance inst *
     & it qty +40
     & it unit +feet)

// Create 20 sec.
// Note: db auto normalized qty "20".
(CREATE time inst *
     & it qty +20
     & it unit +second)

// Create abbreviation for feet and second.
(CREATE type inst *abbr)
(CREATE feet abbr +ft)
(CREATE second abbr +sec)

// Find all things whose qty is 20.
// Returns 20ft and 20sec.
(SELECT * qty 20)

// Find all things whose qty is abbreviated as "ft".
// Returns 20ft and 40ft.
(SELECT * unit (* abbr ft))

// Create verb height to relate distance as height of things.
(CREATE verb inst *height)

// Create person John's height is 20 ft.
(CREATE type inst *person  & dir item it)
(CREATE person inst *john  & it height (SELECT * qty 20  & * unit
feet))

// Create tree1's height is 20 ft.
(CREATE type inst *tree  & dir item it)
(CREATE tree inst *tree1  & it height (SELECT * qty 20  & * unit feet))

// Find all things that are 20 ft in height.
// Returns john and tree1.
(SELECT * height (SELECT * qty 20  & * unit feet))

// Create conversion rate from feet to meter
// and vise versa.
(CREATE type inst *"conversion rate")
(CREATE unit inst *meter)
(CREATE meter abbr +m)
(CREATE feet to meter "conversion rate" +0.3)
(CREATE meter to feet "conversion rate" +3.3)

// Find conversion rate from feet to meter.
// Returns 0.3
(SELECT feet to meter "conversion rate" *)

You have to do that search at http://groups.google.com/; doing it at
http://www.google.com/ is not so helpful (it drops the term
'group:sci.math' from the search and comes up with a number of books).

0.3048, but who's counting.

C J Date does discuss this.  No; but (in his terminology) you do define
a different POSSREP for each set of units within a type.  Thus, you can
define a type for speeds (velocities have direction as well as
magnitude), and you define a different possrep for each set of units you
wish to work with - kilometres per hour, miles per hour, metres per
second and furlongs per fortnight.  The data stored in the DBMS in a
separately defined way - hidden from the user.  When you want a value in
furlongs per fortnight, you simply choose the appropriate possrep when
specifying the value.  Further, if the type designer has done their
stuff properly, you can multiply your value which you think is measured
in furlongs per fortnight by a duration in microseconds and end up with
the distance travelled in metres.  Yes, someone has to think about which
possreps are meaningful and provide some basic functionality, but the
rest pretty much falls into place.

About the only issue that I've not seen dealt with is the ability or
requirement to retrieve the original value as specified by the user,
rather than obtaining the value in some specific set of units.  That is,
I might have (typically legal) reasons for needing to know that the
value was originally specified as 23.45 furlongs per fortnight rather
than, say, 0.01280 feet per second (23.45 furlongs per fortnight * 220
yards per furlong * 3 feet per yard / (14 days per fortnight * 24 * 60 *
60 seconds per day)).  There's an easy way to get any the output in any
particular supported possrep - but not to determine the original possrep
that was used.