johann sorel wrote: > Hi again, > > I asked Andrea and Simone, both are +0 on mutable or immutable. > Martin is for threadsafe, so immutable +1. > > Jody I guess the decision is between us know. > > At which level do we apply the immutability. Style, FeatureTypeStyle, > Rule or Symbolizer ? Thinking.
I liked the idea of FeatureTypeStyle - because it matches my understanding of the problem. And it matches the division between SLD and SE. I understand that it makes things harder to edit - but right now I am using visitors to edit my styles a lot of the time anyways (simply because they are not immutable I must make a copy). See ResizeStyleVisitor for an example of this. So let us think about another angle .... ignoring the division of the SLD / SE what does the renderer (ie portrayal engine) actually use? > I'm fine with FeatureTypeStyle or Symbolizer. Both are valid choices > to me, one is the OGC SE specification extend, the other one is a > renderer need. This is the part I do not understand - what is the renderer need? My understanding is that the renderer need is at the FeatureType style level? ie Features are thrown at the renderer one at a time... - FeatureType style checks if the Fetaure matches (or if any of the Features super types match) ... - And then min / max scale - And then we have Rule which evaluates against the current Feature ... - And then we have symbolizers... So to my mind these data structures FeatureTypeStyle / Rule are involved in the rendering; if they changed while I was reading Features out of a file I would get confused. I understand that symbolizers actually describe how to "stroke" the geometry onto the screen; we also need them to stay immutable. > Could you give me your choice now so that I apply the changes on the > style branch I have. So first - is my understanding of how FeatureTypeStyle is used correct? Secondly let me imagine how if they are mutable - we should copy FeatureTypeStyle / Rule / Symbolizer List before rendering. Note *just* the SymbolizerList is fine; they can keep the same references to the Symbolizers. Copying the FeatureTypeStyle / Rule / Symbolizer List just needs to be done before the rendering starts - at the start of rendering. It is not done once per feature; so this should be okay. In trade we have the ability to fiddle with Filter and the list of symbolizers - the data structure is more friendly to work with. That sounds like a good trade. So classic trade off: - Easy: allow the data structure people want to mess with to be mutable; take an extra step before rendering to copy a few pointers around... - Correct: immutable; force people to copy the style when editing ... I am going to have to agree with you Johann; in this case it pays to be Easy rather than Correct. We should make this requirement evident in the interface - both so we can document and so we can implement it once in a public spot for people to find. So what do we call a method like that? - FeatureTypeStyle.copyBeforeUse(); // very obvious; return a copy before use -or- - FeatureTypeStyle.toPrepairedStyle(); // returns a copy of the provided Style; implementations may optimize -or- - do you have any ideas? What do you think? Jody ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
