Issue 17053: Add a Distance Class to the Standard (tacsit-ftf)
Source: SimVentions (Mr. Matthew Wilson, mwilson(at)simventions.com)
Nature: Revision
Severity: Significant
Summary: Using this as an object rather than a plain double value is a cheap way to avoid costly errors.  NASA lost a $125 million Mars orbiter because one team was using imperial units instead of metric.  Representing distance as an object makes it glaringly obvious in the code which calculations are using which units.

Consider the following method of Rectangle:
	double getHeight();

Embedded in the comments of the interface contract is that “getHeight()” returns a double in meters.  But that’s not at all obvious in client code that uses getHeight(), especially if it’s 2 or 3 levels removed from the place it is called.
Instead, if it were changed to:
	Distance getHeight();

Distance could have methods “double getMeters()”, and “double getFeet()”, that make it immediately obvious what the returned value represents.

If adopted, the following changes should be made:
•	GeodeticPosition
o	Change altitude property from double to Distance
•	Rectangle
o	Change getHeight() to return Distance
o	Change getWidth() to return Distance
•	Circle
o	Change getRadius() to return Distance
•	ViewEyeProperties
o	Change get/setRangeScale to use Distance
•	Viewport
o	Change scaleToPoints(points, margin) margin parameter to Distance
Resolution:

A Distance class has been added to the specification and referenced in the places suggested.

Revised Text:

STILL NEED TO IMPLEMENT THIS IN THE SPEC.

Resolution: 
Revised Text: 
Actions taken:
January 26, 2012: received issue
Discussion: 

End of Annotations:=====
s is issue # 17053


OMG Issue No:  17053
Title:   Add a Distance Class to the Standard
 
Source:
Matt Wilson  - mwilson@simventions.com
 
Severity: Significant
 
Summary:

Using this as an object rather than a plain double value is a cheap way to avoid costly errors.  NASA lost a $125 million Mars orbiter because one team was using imperial units instead of metric.  Representing distance as an object makes it glaringly obvious in the code which calculations are using which units.

 

Consider the following method of Rectangle:

            double getHeight();

 

Embedded in the comments of the interface contract is that .getHeight(). returns a double in meters.  But that.s not at all obvious in client code that uses getHeight(), especially if it.s 2 or 3 levels removed from the place it is called.

Instead, if it were changed to:

            Distance getHeight();

 

Distance could have methods .double getMeters()., and .double getFeet()., that make it immediately obvious what the returned value represents.
 
If adopted, the following changes should be made:
·         GeodeticPosition
o   Change altitude property from double to Distance
·         Rectangle
o   Change getHeight() to return Distance
o   Change getWidth() to return Distance
·         Circle
o   Change getRadius() to return Distance
·         ViewEyeProperties
o   Change get/setRangeScale to use Distance
·         Viewport

o   Change scaleToPoints(points, margin) margin parameter to Distance
Resolution:
 
A Distance class has been added to the specification and referenced in the places suggested.