O.K.
SS
On 4/27/07, Martin Davis <[EMAIL PROTECTED]> wrote:
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
-------------------------------------------------------------------------
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
