Re: [Geotools-devel] Re: Last revision of parameters

[David Z. <dz...@re...>]

On Tue, 2004-10-19 at 16:24, Martin Desruisseaux wrote:
> David Zwiers a =C3=A9crit :
>=20
> > Heya Martin,
> >=20
> > I agree with the existence of a naming issue. I prefer a suffix as we=
ll,
> > but I am concerned with the possible confusion of ...GEO and ..._GEO
> > trying to figur eout off hand whether it is geoapi or geotools. The '=
I'
> > just isn't very appealing.
>=20
> Maybe GT then, as you suggested.
>=20
>=20
> > I guess I should make a suggestion ... my preference is to have the
> > default as an inner class of the interface, but that isn't always
> > possible (and would be a case of calling the kettle black with my sch=
ema
> > stuff).
>=20
> Inner class is really not possible in the case of implementation of=20
> GeoAPI interfaces.
>=20
>=20
> > ParameterValueGT (Geotools)
> > ParameterValue   (GeoAPI)=20
> >=20
> > I would rather have the interfaces maintain the 'original' name, and =
the
> > implementations add postfix initials to distinguish themselves.
>=20
> I agree that interfaces should have the original name. The "GT" suffix=20
> for Geotools implementations seems a good choice. It keep rooms for=20
> other suffix like "JTS" for Geometry wrappers around JTS objects.
>=20
> Wonder if we should put a "_" in front of the suffix, e.g.:
>=20
>     ParameterValue_GT
>=20
> The reason is that some GeoAPI interfaces already have a suffix. For ex=
ample
>=20
>     CartesianCS       (GeoAPI)
>     CartesienCS_GT    (Geotools)
>     GeographicCRS     (GeoAPI)
>     GeographicCRS_GT  (Geotools)

I like it, sounds like a good plan to me.

David
>=20
> It would also separate visually the suffix (which is about=20
> implementation) from the name (which is about functionality).
>=20
>=20
> 	Martin.
>=20