Le blog à Fred

Most of the people coming here know that I'm an Ada enthusiast.
In my job, I'm mostly developing in Java and one of the remarks I got in the past about Ada type system is that it's useless.
A lot of developers are arguing that they never have bugs due to a type error. So, the use of range constraints and so on in Ada are almost seen as useless verbosity.
For once, I've another point of view about this feature and it's not related to bugs but to maintainability.

The reason

It's not really a secret that I'm working on cartographic products. Our product is written in Java and we use OpenMap for displaying some kind of maps.
Few weeks ago, we found that the old version of OpenMap we were using contained a bug about a specific raster format. After looking into the new source code^[1], I found that the bug was still there.
One of my colleague fixed it and provided a patch to the project. Then I decided to test the patch on the brand new version of OpenMap by migrating to the last version.

The problem

Migrating is not always as simple as it might seem.
Between the two versions, 4.6.5 and 5.1.13, there has been a lot of changes that were easily detected by the compiler but the main one only seemed to be a package name change.
The LatLonPoint class was in the past inside the package com.bbn.openmap and changed to com.bbn.openmap.proj.coords.
Ok, that's easy but if I show you the beginning of the code, you will see.

/*
* For version 4.6.5
*
*/
public class LatLonPoint implements Cloneable, Serializable {
    // SOUTH_POLE <= phi <= NORTH_POLE
    // -DATELINE <= lambda <= DATELINE
    public final static float NORTH_POLE = 90.0f;
    public final static float SOUTH_POLE = -NORTH_POLE;
    public final static float DATELINE = 180.0f;
    public final static float LON_RANGE = 360.0f;
    // initialize to something sane
    protected float lat_ = 0.0f;
    protected float lon_ = 0.0f;
 
    public final static float EQUIVALENT_TOLERANCE = 0.00001f;

And the newest one

/*
* For version 5.1.13
*
*/
public abstract class LatLonPoint extends Point2D implements Cloneable, Serializable {
 
    /**
     * 
     */
    private static final long serialVersionUID = 4416029542303298672L;
    public final static double NORTH_POLE = 90.0;
    public final static double SOUTH_POLE = -NORTH_POLE;
    public final static double DATELINE = 180.0;
    public final static double LON_RANGE = 360.0;

Do you see ?
First of all, the class is now abstract... You can imagine what happened in my code as this class is really centric
So how do you create LatLonPoint ?
Inside the LatLonPoint, you have two inner classes defined as follows

public static class Float extends LatLonPoint {
 
        /**
         * 
         */
        private static final long serialVersionUID = -2447464428275551182L;
        protected float lat;
        protected float lon;
        protected transient float radLat;
        protected transient float radLon;
 
[...]
 
/**
     * Double precision version of LatLonPoint.
     * 
     * @author dietrick
     */
    public static class Double extends LatLonPoint {
        /**
         * 
         */
        private static final long serialVersionUID = -7463055211717523471L;
 
        protected double lat;
        protected double lon;
        protected transient double radLat;
        protected transient double radLon;

This was done to mimic the Point2D class but everywhere I instanciated a LatLonPoint, I now need to choose between Float or Double version.
Ok but what happens if I prefer to keep the higher abstract view ?
Well, for getting latitude in degrees the type returned is float whereas for radians, it's double.
Mixing such kind of types creates a mess inside our application because everything was float in the past.

The Ada solution

First try

A first solution might be to declare types for latitude, longitude and radians.

type Latitude is digits 10 range -90.0 .. 90.0;
type Longitude is digits 11 range -180.0 .. 180.0; -- for 7 digits after dot
type radian is digits 15 range -2*π .. 2*π; -- with π from Ada.numerics
 
type LatLonPoint is private; -- which should define the way we store the coordinates

The problem is that the client code don't have any way to change the precision the same way Java more or less allows it.
It's time to extend the functionalities with generics.

Second try

It would be better for the client code to define the precision.
Here is one solution... But I'm sure there's something clever than this^[2]

generic 
	type real is digits <>;
package coords is
   type latitude is new real range -90.0 .. 90.0;
   type longitude is new real range -180.0 .. 180.0;
   type radian is new real range -2*π .. 2*π; -- with π from Ada.numerics
 
type LatLonPoint is private; -- Using the types defined above
end coords;

You should wonder why not using Real types directly. First, because I want the compiler to check as much as possible.
Second, because I don't need the precision of a Java double.
Let me explain :
With 7 digits after the dot for a latitude in decimal degrees, two latitudes in my code will be distant at equator level from 1 centimetre.

Conclusion

By providing the precision on the client side through a generic unit, it is possible to avoid the types mixing we had with the Java version while keeping type safety.
Changing precision is a client decision and not a implementer one. This way, the compilation problem^[3] can be avoided.