I'm not trying to say that there on only one right way to do things,
however the basic JUMP design is a very good one, and consistency in
return values for the methods of a class is not necessarily something
to strive for.
In the case of getFeatures(), the main accessor method of the class,
it is
Stefan is correct that Lists have more methods, although technically
Collection is an interface not a super class. The List interface is a
superset of the Collection interface. Notably it adds the important
positional access methods. Of course, Lists also have order which all
Collections do not
mhm.. to my knowledge the collection is the super class, thus lists have
more methods.
so you can not cast from collection to list but the other way around???
stefan
Sunburned Surveyor schrieb:
> Stefan,
>
> I'm a little confused. A List is an implemenation of the Collection
> interface. I tho
Stefan,
I'm a little confused. A List is an implemenation of the Collection
interface. I thought it would make more sense for the FeatureCollection
interface to return an implementation of Collection, rather than a List
specifically, becuase it gives the programmer implementing the interface
more
although you already respond with an ok.
i just want underline what Martin said, because a list has much more
features. and i guess alsmost everybody uses these nice features?
But It may be possible to add a second method - if one prefers to get a
collection :)
stefan
Sunburned Surveyor schrie
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 pre
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
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 R
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 remove
