Motivation: |
Make GeoAPI implementation class names consistent |
|---|---|
Contact: |
|
Tracker: |
|
Tagline: |
|
Implementation of GeoAPI classes have different naming pattern in different modules. In the referencing module, they are prefixed with Default or Abstract. In the metadata module, they are suffixed with Impl. This proposal is about a more consistent pattern to be applied at least accross the metadata, referencing and coverage modules. More specifically we suggest to adopt the Default/Abstract prefix scheme used in referencing, and rename all metadata implementation classes accordingly.
Impl suffix was to preserve alphabetical order. However experience suggests that it is not so convenient, since it is often more useful to distinguish between GeoAPI implementations and GeoTools specific classes. The GeoAPI implementation could be hiden from the "beginer" javadoc (make is visible only to "advanced" users). Most users could be encouraged to read the GeoAPI javadoc instead.AbstractCS (the base class for DefaultCartesianCS, DefaultVerticalCS, etc.) is abstract according ISO, but not in the Java sense since it can be instantiated. Actually AbstractCS is really instantiated in a few cases by the WKT parser, meaning "I really don't know what this coordinate system is; I just know its axes" (this case occurs because of limitations in WKT syntax).Example: The CRS package has the following classes. We can see immediately that CRS, SingleCRS and DerivedCRS are abstract (in ISO sense), and that UnprefixedMap has nothing to do with GeoAPI classes. We would like the same advantages for metadata.
Impl suffix by Default or Abstract depending on whatever the class is abstract or not according ISO.Impl classes as extending the new renamed classes, and deprecate them for GeoTools 2.5 release.Impl classes on trunk after GeoTools 2.5 release.No other classes than metadata would be renamed at this stage; current class names in referencing and coverage are considered okay.
Note that a few referencing and coverage classes use other prefix than Abstract or Default. For example "General" in GeneralEnvelope to stress-out its n-dimensionsl aspect compared to Envelope2D, or "Grid" in GridSampleDimension to stress-out that they apply to GridCoverage rather than arbitrary Coverage. This is okay and don't need to be forced into a Default/Abstract naming scheme. The above is just a proposed rule of thumbs, not a strict rule.
Voting is open:
Community support: