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 ? 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. Could you give me your choice now so that I apply the changes on the style branch I have. regards > Jody Garnett a écrit : > >> What do you think about the idea of making FeatureTypeStyle and below >> (ie the Symbology Encoding Specification) immutable? If you think it can >> be done I would like to see it happen. >> >> I agree with Andrea that being consistent is good. Symbolizer is an >> "easy" place to draw the line at the coding level. I think we kind of >> have to draw the line at the Rules level to be successful; ie a Rule >> captures a Filter and scale range? We don't want that changing mid renderer. >> >> If I keep thinking that way the first logical place to stop is >> FeatureTypeStyle; which is also where the Symbology Encoding >> Specification ended up stopping. >> >> Cheers, >> Jody >> >> > I dont think that the Rule or FeatureTypeStyle are really good levels. > If you want to have something consistent you should start at the Style > level. > this means having : style, fts, rule, symbolizers .... immutables. > > The style interfaces are like a tree model with the root style node. > If everything is immutable, imagine what you'll have to do to just change > a symbolizer's place or even change an Expression parameter because you > forgot a > quote. you'll have to "copy" the all tree for a single leaf. > > Style is a too big model to be made immutable. same thing for FTS and rules. > Symbolizer is small enough to be made immutable. > > Beside I dont really think there is a consistency problem. I see the > Symbolizer as > the "atome" element in styles, it's the first and only style element > that can be used > on it's own and it's also the first element that holds informations > about rendering. > Style, FTS and rules are only "guiding" objects. > > > Making everything immutable brings another problem for statefull renderers. > If you replace the style in one operation, we must assume it is a > different style and rebuild > the style cache from scratch because you dont know what has changed compared > to the previous one. -- Johann Sorel Company - Geomatys GIS Developer Mail - [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
