Martin Desruisseaux ha scritto: > Justin Deoliveira a écrit : >> * ComplexAttribute.getValue() to List >> >> +1 on this one. A list is still more useful even if you are telling >> people that the order in the list may be random. > > The only comment I could make on this feature review is related to > collections. > I have the feeling that many peoples love java.util.List and don't like the > other collection interfaces... On a pure "principles" point of view, if the > order is not relevant, I would be tempted to suggest to stick to > java.util.Collection. I would like to know why peoples find List so much more > convenient? Is it because it provides a way to avoid the additional verbosity > of > using an Iterator? If so, could the new Java 5 language features make it easy > enough to solve this issue? > > > Andrea Aime wrote (from the PDF document) >> I don't see how casting down getProperties() to Set<Property> does any >> good at explaining better than only a single attribute can be chosen. >> Collection<Property> or List<Property> would be the same, the check >> should be put in a restriction filter and is otherwise >> explained only in the javadoc of the class. > > If the properties is expected to contains only singletons, I find nice to > publish that as an explicit Set interface. Is there any reason why a user > would > like to access a property by index? > > We had a similar issue in GeoAPI metadata; some methods returning Number were > changed to Double because users wanted to publish the expected "kind" of > number, > even if it adds nothing on an API point view.
Sigh, either people are only commenting on Justin comments without reading my review, or I did a really horrible job at writing the review... probably the second. I have "Spring into technical writing" sitting in my library, it's probably time I read it... My reason for preferring List to Collection has nothing to do with syntax (in fact I only use iterators to scan collections of every type, it's an habit I have, even when I know I'm playing with ArrayList where index based access would be more efficient). Citing from my review: "The whole model makes it explicit that when you're asking for a value, you don't get one, but a Property instead. The first reaction is, why would I need to get metadata along with data, isn't the feature model enough? The javadoc does not tell, but ComplexFeature.getValue() is returning a collection and not a list, so no ordering is implied. Well, I did not notice but this goes all over the API. Why in the world aren't List<xxx> used instead? That would allow for an ordering assumption and would make things that much easier? (no need to carry both data and metadata togheter, just return the value like SimpleFeature does?). I guess I'm missing something, but you'll have to tell me what that is." Rewording this, using List instead of collection in FeatureType would allow Feature to return the attribute values right away instead of wrapping them into Property objects. This feels more natural to me, simpler, and has less overhead (don't discount this last bit, we are going to play with million of features). Using List in both places allow positional correspondence, so if I need to know what Feature.attributes[3] is, I just have to call Feature.getType().getAttributes[3] and I have the descriptor without the need to keep it straight in the data. Use of generic "Collection" forces a mixture of data and metadata which seems to be unnecessary evil to me. Oh, about the usage of Set... I don't really care. Yeah, I know the java API has Collections.singleton(o), but there is also Collections.singletonList(x) and Collections.singletonMap(k, v). A collection with a single value is just that, by using Set you're not telling anything about its singleton-ness, it's in the javadoc not in the interface. If you really wanted to tell, you could create a class Singleton extends Collections sporting and a single getValue(): Object method to grab its contents. Anyways, this is a very minor issue, the real one is the data/metadata mix I see above. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
