On Thu, 2008-06-26 at 23:10 -0400, Jody Garnett wrote:
> This method was lame; it was exactly the same as calling
> - attributeType instanceof GeometryAttributeType
>
> So if you have code like that please check to see if your
> - attributeDescriptor instanceof GeometryAttributeDescriptor
>
Do you mean GeometryDescriptor and GeometryType?
Assuming you do, doesn't such a check seem brittle, as it depends on the
actual underlying implementation of the GeoAPI? (In the case of
GeoTools, this is obviously irrelevant, as the implementation is what it
is. In the more general case, however, this is troubling.)
Suppose that in some fictional GeoAPI implementation I write a class
that creates AttributeDescriptor objects. Now, some of these
objects /could/ technically be created as GeometryDescriptor objects,
but there is nothing in the interface contract that requires me to do
that. I could happily return an object whose type implements
AttributeDescriptor but not GeometryDescriptor. In this case, a direct
cast would fail at runtime. (And an instanceof check would return false,
which would be misleading.)
It seems that in this case an explicit conversion is needed, which would
necessitate a method to check to see if conversion is possible, asÃ:
interface AttributeDescriptor {
...
boolean isGeometryDescriptor();
GeometryDescriptor asGeometryDescriptor();
...
}
Assuming that every AttributeDescriptor that is convertible to a
GeometryDescriptor actually /is/ a GeometryDescriptor at runtime creates
a hidden requirement on anyone who implements the GeoAPI.
At the risk of repeating myself (since I just thought of another way to
say it), I think there's a risk in this blurring of the lines between
the Java object hierarchy and the abstract data model. Assuming that any
object that is created is always the most specific type it possibly can
be seems like a bad idea.
>
> You will also find that GeometryAttributeDescriptor allows:
> - you to hold an Object for the Geometry; so we can move on past JTS
> Geometry
> - reports back the CoordinateReferenceSystem and Bounds
>
> (if I remember correctly).
> Jody
> PS. you are having a whole bunch of talented questions; it would really
> help if you had either commit access (for helping with javadocs) or wiki
> access (for jotting notes down for the next person :-)
> PPS. yes GeoTools is accepting volunteers ;-)
>
Thanks for the vote. I'll have to see about it. The work I'm doing
currently is my job, not my hobby, and unfortunately at the moment I
don't have time for another hobby.
However, if it's ok with my employers, I'd be happy to do some work here
and there to write up what I've taken in so far. I have several pages of
notes that might (if cleaned up) make decent user manual material.
P.S. Sorry about the signatures. They're automatically generated by our
mail server and sometimes it goes in the wrong place.
Thanks,
Tim Swanson
Tim Swanson
Software Engineer
Tyler Technologies, Inc.
14142 Denver West Parkway, Suite 155
Lakewood, CO 80401
Phone:
Fax: 303-271-1930
E-mail: [EMAIL PROTECTED]
Web: www.tylertech.com
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
