On Mon, Mar 28, 2005 at 03:40:14PM -0500, Aaron Sherman wrote:
: Now you can ask for whatever you like:
:
: say "We have {â.new $money}â"
:
: Though you might have some snazzy way of saying that.
Just by the by, that's illegal syntax. Methods with arguments
require parens. You could, however, say
say "We have {new â: $money}â"
: > The real "fun" in determining what should happen with units comes to
: > when you do operations that _change_ the units.
Doing the proper dimensionalysis, that's really just a specialized form of type
inferencing, I expect.
: > my $Current = 5`Amps;
: > my $Resistance = 10`Ohms;
: > my $Power = $Current * $Resistance; # Do I get 50`Watts here?
:
: Again, if Amps and Ohms know that they can do that, then you're all set.
: Otherwise, you just construct a new value like so:
:
: my Watts $Power = $Current * $Resistance;
:
: Which again are probably all aliases for Units::Physics::*
I've always thought that we should make use of the database of the
"units" program for standardized names of units. The units database
has a pretty good list of which units are just differently scaled
units of the actual underlying fundamental dimensions, and a lot
of encoded experience in distinguishing ambiguous units names. It'd
be a shame to reinvent all that.
But the basic underlying principle here is just the same as with
characters. Define your formal parameters in terms of the fundamental
dimensions like Length and Time, and let the computer worry about
the scaling issues. I consider types like Velocity and Acceleration
to also be fundamental in that sense, even though composed of other
fundamental dimensions, so it's not necessary to write Length/Time
or Length/Time**2 (however you care to spell those types).
It is this sense in which Position or Ptr is fundamental, even though
it is a location in a particular string at a particular time.
Larry
