James Macgill wrote:
I do like the idea of helper methods and classes for develoeprs but I
worry about hiding them inside the implemenation classes. In your
example last() would work for any implemenation of List so why hide it
inside the implementation?
Because client code knows what they are doing, and if they are using our
implementation we can make their
life easier.
Easier then what? Easier the using a minimal GeoAPI interface. Note we
would only be doing this for
the benfit of users, as internally we should code towards an minimal
interface designed for interoperability.
To be blunt - we have three kinds of users:
- client code (user/end users) = using the geotools implementations to
hack spatial data - any help we can be to them the better
- extenders (power users/jesse) = want geotools to work with custom
implementations of ... well anything (common example from JUMP making an
application object support the Feature interface and expecting it to
*work* for all vislization & lifecycle & events)
- geotools developers (module maintainers) = similar concerns to above,
but we need them to respect the interface limitations so that extends
can interact correctly.
Client code can make an assumption that we cannot - classic trade off.
Given the breakdown above don't really see that we can go with anything
other then a minimal interface for things that may be extended.
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
