Ok, but I still dont understand why you are against changing the method name from getIDs to getIdentifiers ?
Jody Garnett wrote: > Your second idea works, and I carefully defined Identifier.toString() to > be the textual representation of the identifier so you > should be good. > > Jody >> This still doesn't help me. I will still get a bunch of exceptions with >> client code trying to cast to String. The whole point of changing the >> method name is that i could hunt down all those instances, and as a >> client I know where things will break, as you say getting the compiler >> to help me. >> >> This is a pretty nasty way to break the api, by changing the type of a >> collection but keeping the name the same. >> >> Anyways, I guess I can just change the name locally and hunt down all >> instances of client code that uses this. Should only take a few days... >> >> Another alternative would be perhaps a convenience method on Id that >> instead of returning a set if Identifers, would return the underlying >> values, in the case of FeatureId, a set of strings. >> >> -Justin >> >> Jody Garnett wrote: >> >>> Justin Deoliveira wrote: >>> >>>> Jody Garnett wrote: >>>> >>>> >>>>> To be clear, both GeoTools and GeoAPI assumed strings would make good >>>>> identifiers. >>>>> The filter specification: >>>>> a) strongly types identifier (FeatureId, GMLObjectId, RecordId, ...) >>>>> b) allows for non String, or compound identifiers (ID and VERSION >>>>> anyone?) >>>>> >>>>> Justin for your first cut do you want to just use FeatureId at the Java >>>>> 1.4 level? I will need >>>>> to relax that for an ObjectId next week, but it would let the compiler >>>>> help you this week. >>>>> >>>>> >>>>> >>>> Not sure what you mean by "using FeatureId at the Java 1.4 level"? >>>> >>>> >>> I was thinking you may want to "assume" the FeatureID subclass of >>> Identifier this week when doing the GeoAPI type erasing. Although I bet >>> it only shows up as a Set<Identifier> anyways... Tell you what I will go >>> start in on using Filter w/ Pojo so we can try an implementation of >>> ObjectId as well. >>> >>> Near as I can tell to "teach" geotools about new content we need: >>> - an Identifier implementation for the content >>> - a XPath implementation for the content (even if limited) >>> >>> Cheers, >>> Jody >>> >>> >>> >>> >> >> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:1004,4547a0e857581804284693! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
