Re: R: [Geotools-devel] Thoughts on the new Feature interfaces.

[Chris H. <ch...@op...>]

> I'm sorry I missed this topic from the start, so I didn't give
> my opinion from a client code point of view.
> Now it seems much too late, but I would like to say a few things.
>
> .) I wouldn't change the interfaces for whatever reason.
> Feature, FeatureType, etc. are used everywhere in client code,
> so I'd consider them cast in stone.
>
> .) If I got it well, you're saying that, for example:
> 	Object Feature.getAttribute(int index);
> will become:
> 	List Feature.getAttribute(int index);
> I feel that 90% of Feature will have zero-multiplicity, so List
> should
> be the exception and Object the rule, not the other way around.
> At the same manner there should be no SimpleFeature, because all
> Feature
> should be simple by default.
>
> .) Maybe I got it wrong and:
> 	Object Feature.getAttribute(int index);
> will stay like that but the Objects will always actually be Lists.
Yes, this is more the thought.  But actually not always Lists, they
would be the single Objects in SImpleFeature, and Lists in non Simple
Features.  My thought is to work out knowing which is which.

> In any case I wouldn't add a toComplex() nor a toSimple() method,
> nor I'd create a SimpleFeature or ComplexFeature interfaces.
> I'd create a ComplexWrapper class that lets multiplicity-inclined
> client
> code
> wrap all its Feature instances inside a List view.
> I'd also create a SimpleWrapper class that lets NON
> multiplicity-inclined
> client code
> be sure to use all Feature instances as simple Objects.
Well, I don't know that just wrapper classes would be sufficient.  I
think we may need the interfaces, to allow for other implementations. 
It seems to me to make more sense to have a SimpleFeature interface,
and the DefaultFeature would be a SimpleFeature, which would could just
call instanceof Feature.  It seems to me with a SimpleWrapper class,
and no SimpleFeature interface, you would get a Feature, wouldn't know
what it was, and thus would have to put it in a SimpleWrapper, going
through the process of creating a class, instead of just an instanceof
to figure out what you are working against.


>
> .) I also feel no need to add something like:
> 	getAttribute(int typeIndex, int attIndex,Object val)
> the Object val "is" the List, so you can get/set individual values
> directly
> from it.
> The List instance can be backed directly by the Attribute, so a
> change to it
> would be directly reflected to the Attribute itself.
> Or the List can be standalone, so it needs to be completely set back
> to the
> Attribute to apply changes.
Yeah, that makes sense.  My bad.

>
> .) Treating the List as a unique, albeit composite, value has also
> the
> advantage
> that you can validate it as a whole inside the Attribute (for example
> you
> may
> have a requirement that a List must be always composed of four
> elements).
Yeah, that's exactly the kind of validation we want to do.

>
> I hope I added something useful to the discussion and that I didn't
> wasted
> your time
> (and mine also:).
No, not at all.  It's been hard to get good feedback on this, as some
people aren't taking the time to read through all the issues.  It is
very valueable knowing what you want, and it is not all completely set,
since the implementations aren't there yet.  We got the main ideas in,
now we need to hash out the particulars of how the individual methods
will work.

Chris

>
> Bye
> Paolo Rizzi
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Geotools-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/