Re: Engineering types hierarchy

[dkristol@see-my.sig (David Kristola)]

In article 37d663dd@news1.prserv.net, "Matthew Heaney" <matthew_heaney@acm.org> () writes:

>In general, I like to keep it simple, and just name (scalar) types with
>their units:
>
>  package Ownship is

Ownship, that brings back memories!  (BSY-2, Seawolf submarine :-)

{snip}
>As you've already discovered, other approaches engender a combinatorial
>explosion.  There's no way for you to know up front which conversions you're
>going to need, so just declare a minimal set (for length, mass, and time,
>say), and leave it up to the client to combine the primitive units
>conversions into the complex units he needs locally.

I am trying to keep it simple, however, the problem domain
is not cooperating ;-).  A number of different packages need
the same subsets of units and operators, and often they
communicate in these units.  I have to pass torques around
(Newton_Meters_Type), and many other combinations.

At this point, conversions don't seem to pose a problem
(we will be working in meters, and not have to convert to
millimeters and kilometers and centimeters).  But we are
moving through many different algorithms, and using many
different unit combinations.  Sensors bring in data in one
form, it then gets combined with inertia data and commands
to form torques and eventually currents (and this is just
the subsystem i am worrying about).

The first try at the types package is working out well.
Once the operators are in place, and constants and variables
are properly typed, the algorithms are real clean.  And
units are being checked at compile time.  But if there is
a better way that fits our needs, this is the time to
make the change.

Thanks,
--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com