Jody Garnett ha scritto: > Andrea Aime wrote: >> I understand. Yet I feel we lack a middle ground allowing to represent >> associations in an efficient way, the same way deegree did. > (In my benefit/complexity table this whole multiplicity thing is a good > tipping point) > > I still don't see why it could not just be an implementation options; if > an implementation wants > to keep several values as an array and dish them out one at a time for > the getValues() method > that is cool. The fact that they would be able to answer a Collection > getAttribute( name ) question > very quickly and efficiently would be fine as well.
Nope, this would be memory efficient, but not time efficient. Memory allocation in java is fast, but not free... think the whole optimization process related to substituting Coordinate[] to double[]. Anyways, one thing, does ComplexAttribute.get(Name name) need to return a List<Property>? Or we can have a fast path returning List<Object> (the property values) here? I guess the question boils down to wheter Name is a full xpath representation (with wildcards and whatnot) or is just able to represent the path to a nested attribute? The javadoc does not tell (or at least, I don't see it). 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
