Actually, I like simple. That means in a deployment not having to download all the data to guess what it means.
I feel its always worthwhile considering as many perspectives as possible during a design decision. Engineering performance of current implementations is a valid perspective, but its not the only basis for designing future implementations! That would be like saying we can never get to the moon because the horses would need too much hay when they get there. Identify a simple implementation pattern and applying approrpiate optimisations makes perfect sense to me, but I'd rather not complicate the code base by pretending its anything other than an optimisation. Otherwise, we will get massive amount of hacks and tweaks to functionality for special cases smuggled into an optimisation strategy, instead of making the whole thing work properly. We can see how pursuing the (perfectly valid) optimisation to the exclusion of all else has led to such a major hurdle getting a little bit more functionality. rob On Mon, Mar 2, 2009 at 9:32 AM, Jody Garnett <jody.garn...@gmail.com> wrote: > Thanks for applying that Justin. > Rob they are mostly talking about the implementation side here; > SimpleFeatureType will still extend FeatureType at the API/interface level. > We just have slightly different implementation needs well with in the bounds > of what is expected. > On a related note Ben; when thinking about the SimpleFeature interface > please understand that it does not meet the needs of GML SimpleFeature > profile (it has reduced scope and is really focused on meeting the > basic/shapefile idea of a Feature). > Cheers, > Jody > > On Sat, Feb 28, 2009 at 9:28 AM, Rob Atkinson <robatkinson...@gmail.com> > wrote: >> >> Great to see the progress, and such constructive support from the >> community. >> >> I'm not so sure I like the sound of moving the SimpleFeatureType out >> of the hierarchy, though I suppose it does implement the >> GeneralFeature API... >> >> (warning - rhetorical question) Why do we want a SimpleFeature at all? >> It seems to me to be partly to implement an implied contract with all >> the previous users of Feature, not because there is any intrinsic >> reason that any of the previous uses actually needs to have the >> constraints of Simpleness enforced. >> >> So, other than this, the other reason would be to make the contract >> explicit, so that optimisations could be applied by some clients. >> >> Is it feasible to reduce unnecessary SimpleFeature usage rather than >> split it out? You can perhaps then retire a code for "retyping" and >> hacks around things like "name" >> >> Just 2c for consideration, >> >> On Sat, Feb 28, 2009 at 6:01 AM, Justin Deoliveira <jdeol...@opengeo.org> >> wrote: >> > Patch applied. Shall we open a new issue for breaking simple feature >> > type out of the complex type class hierarchy? >> > >> > Justin Deoliveira wrote: >> >> Ok, I propose applying Ben's patch for the moment since simple feature >> >> type is pretty clearly broken. And make the clean break from the super >> >> class a separate issue. >> >> >> >> Jody Garnett wrote: >> >>> Hi Ben sorry to be slow to respond to this one; I am busy prepping for >> >>> a >> >>> meeting with Simone. I do have your patch applied but have not been >> >>> able >> >>> to review it carefully yet. >> >>> >> >>> Justin you are correct about the duplication being an issue; I am >> >>> still >> >>> keen to make a SimpleFeatureType / SimpleFeature implementation that >> >>> is >> >>> lean and does not extend another class. >> >>> >> >>> Jody >> >>> >> >>> On Fri, Feb 27, 2009 at 5:05 PM, Justin Deoliveira >> >>> <jdeol...@opengeo.org >> >>> <mailto:jdeol...@opengeo.org>> wrote: >> >>> >> >>> Hi Ben, >> >>> >> >>> >> >>> Ben Caradoc-Davies wrote: >> >>> >> >>> Justin, I have no objection. It should do no harm. However, >> >>> note >> >>> that: >> >>> >> >>> (1) order should never be important, except for special case >> >>> subclasses such as SimpleFeatureTypeImpl (see below), and >> >>> >> >>> I guess the contract does not specify any order... but it just >> >>> seems >> >>> like a good thing to do implementation wise. Unless there is a >> >>> strong case for changing the order... since types are immutable i >> >>> can't think of one. >> >>> >> >>> >> >>> (2) LinkedHashMap conforms to the Map contract, which >> >>> guarantees >> >>> that order is *not* significant for equals/hashCode. Fixing >> >>> iteration order does not fix this. >> >>> >> >>> Good point, something i missed when reading the javadoc of >> >>> LinkedHashMap. >> >>> >> >>> >> >>> I experimented with using LinkedHashMap in ComplexTypeImpl to >> >>> fix SimpleFeatureTypeImpl iteration order, but when I realised >> >>> it did not fix equals/hashCode, I made all my changes to >> >>> SimpleFeatureTypeImpl. If you support my position, please join >> >>> me in nagging Jody to get my patch accepted. Please take a >> >>> look >> >>> at it; the patch comes with unit tests for iteration order >> >>> consistency: >> >>> http://jira.codehaus.org/browse/GEOT-2338 >> >>> >> >>> More importantly, why do you want to change the order of >> >>> properties? Do you have a non-simple use case in which they >> >>> matter? If not, please consider my patch. >> >>> >> >>> Indeed this is the exact case addressed by the patch, calling >> >>> getDescriptors() and it returning descriptors in a different >> >>> order. >> >>> So I am +1 on fixing this at the simple feature type level if the >> >>> current behavior of complex feature type is deemed necessary. The >> >>> patch looks good however the duplication of storage of descriptors >> >>> for simple feature type seems wrong... perhaps >> >>> SimpleFetaureTypeImpl >> >>> should not extend ComplexFeatureTypeImpl. >> >>> >> >>> >> >>> Kind regards, >> >>> Ben. >> >>> >> >>> >> >>> Justin Deoliveira wrote: >> >>> >> >>> Sorry, i did not mean tree map, just a map with >> >>> predictable >> >>> iteration order. LinkedHashMap should do the trick. >> >>> >> >>> Justin Deoliveira wrote: >> >>> >> >>> Hi all, >> >>> >> >>> I think Ben may have brought this up recently, but >> >>> looking at ComplexTypeImpl it seems property values >> >>> are >> >>> stored in a hash map, which totally throws away the >> >>> order in which property descriptors are added to it. >> >>> >> >>> Any objection to making this a tree map as to maintain >> >>> order? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Justin Deoliveira >> >>> OpenGeo - http://opengeo.org >> >>> Enterprise support for open source geospatial. >> >>> >> >>> >> >> >> >> >> > >> > >> > -- >> > Justin Deoliveira >> > OpenGeo - http://opengeo.org >> > Enterprise support for open source geospatial. >> > >> > >> > ------------------------------------------------------------------------------ >> > Open Source Business Conference (OSBC), March 24-25, 2009, San >> > Francisco, CA >> > -OSBC tackles the biggest issue in open source: Open Sourcing the >> > Enterprise >> > -Strategies to boost innovation and cut costs with open source >> > participation >> > -Receive a $600 discount off the registration fee with the source code: >> > SFAD >> > http://p.sf.net/sfu/XcvMzF8H >> > _______________________________________________ >> > Geotools-devel mailing list >> > Geotools-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
