Hi all,
The current plan for Feature.getBounds() is simply to change the return type of the method from Envelope to ReferencedEnvelope. While this saves client code it does not save people who have implemented Feature or FeatureCollection directly.
As implementing a decorating feature collection is not an uncommon practice I thought I would bring this up as a point of discussion. For instance there are a few breakages that occur in GeoServer.
Thoughts? Shall we keep moving forward with the type change regardless or abort the effort and revert to the rename strategy.
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Hi all,
The current plan for Feature.getBounds() is simply to change the return type of the method from Envelope to ReferencedEnvelope. While this saves client code it does not save people who have implemented Feature or FeatureCollection directly.
As implementing a decorating feature collection is not an uncommon practice I thought I would bring this up as a point of discussion. For instance there are a few breakages that occur in GeoServer.
Thoughts? Shall we keep moving forward with the type change regardless or abort the effort and revert to the rename strategy.
I would say to go on, but I only realized now that this will break
things for 2.4 users directly (only those that subclassed Feature, you're right in saying so).
Harr... the breakage would be minimal, and circumscribed to a few
classes that directly implement Feature, with a 3 lines fix,
whilst the rename and remove thing will generate lots of
work in moving to non deprecated code (since it breaks Feature
clients, not Feature implementors, and thus thousands lines of code).
I'd say to break the interface now, since the damage is minimal.
It's a painful decision, and we'll just give another confirmation to
users complaining that we can't keep Geotools code stable enough... and
indeed we can't. Shame on ourselves 
Well, at least this time we're weighting the less painful breakage....
Cheers
Andrea
Agreed. Its a darned if you do darned if you don't sort of thing. We could maintain no api breakage, but the user (ie GeoServer) will have to change hundreds of lines of code. On the other hand we break subclass api compatibility GeoServer only has to change 10 lines of code...
-Justin
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
The current plan for Feature.getBounds() is simply to change the return type of the method from Envelope to ReferencedEnvelope. While this saves client code it does not save people who have implemented Feature or FeatureCollection directly.
As implementing a decorating feature collection is not an uncommon practice I thought I would bring this up as a point of discussion. For instance there are a few breakages that occur in GeoServer.
Thoughts? Shall we keep moving forward with the type change regardless or abort the effort and revert to the rename strategy.
I would say to go on, but I only realized now that this will break
things for 2.4 users directly (only those that subclassed Feature, you're right in saying so).
Harr... the breakage would be minimal, and circumscribed to a few
classes that directly implement Feature, with a 3 lines fix,
whilst the rename and remove thing will generate lots of
work in moving to non deprecated code (since it breaks Feature
clients, not Feature implementors, and thus thousands lines of code).
I'd say to break the interface now, since the damage is minimal.
It's a painful decision, and we'll just give another confirmation to
users complaining that we can't keep Geotools code stable enough... and
indeed we can't. Shame on ourselves
Well, at least this time we're weighting the less painful breakage....
Cheers
Andrea
!DSPAM:4007,468e7783158795219720167!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org