SS, It's easy to change the FC interface methods return value from List to Collection n the JUMP CVS codebase.
But you risk breaking a lot of external plugins which have been coded to the current interface. I don't really see a pressing need to do this, so I would vote against it. Sunburned Surveyor wrote: > Martin, > > This makes perfect sense. Thank you for the clarification. If no one > has an objection I will make a not of it in the Javadoc API. I might > also see if I can refactor the FeatureCollection interface to use > java.util.Collection on the other two methods. This will give me some > practice with Refactoring. (I won't commit these changes to the CVS > until I know it works and I've had a chance to talk to the other > developers.) > > SS > > On 4/27/07, *Martin Davis* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > The fact that getFeatures and query return a List is probably an > undesirable widening of the API. For maximum flexibility for > implementors, they should all return Collection. This was just an > oversight in the original design. > > The reason that remove(Envelope) returns a collection of the removed > features while the others don't is that in the other two methods the > caller already knows which features are the ones which are to be > removed. In the case of remove(Envelope) the only way to know > what has > happened is to get the method to report which features it removed. > > Sunburned Surveyor wrote: > > I've been working on my FeatureCache and I've got a couple of > > questions about the FeatureCollection interface. > > > > Three of the methods of the interface return instances of > > java.util.Collection. The getFeatures() method and the query() > methods > > return instances of java.util.List, while the remove() method > returns > > an instance that implements the java.util.Collection interface. I am > > wondering why these three methods don't consistently return > instances > > of java.util.List or instances of java.util.Collection. Why is the > > return value of the remove() method different from the other two > methods? > > > > I also noted that there are three methods that perform removal of > > Feature objects from the FeatureCollection, but only one of these > > methods, the remove(Envelope env) method, returns the Feature > objects > > removed as an instance of java.util.Collection. The remove(Feature > > feature) method and the removeAll(Collection features) method do > not > > return the Features removed. Is there a reason why this behavior is > > not consistent? > > > > I'm just curious. It seems the Vivid Solutions team always had > reasons > > for doing things that aren't readily apparent because of my lack of > > programming experience. > > > > Thank you an advance for any clarification. > > > > The Sunburned Surveyor > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
