Sascha, See my comments below.
Sascha wrote: "It would be nice to have a "immutable policy" for coords and geometries but we'll have to catch all the horses first." Like I said above, I recognize that it would be difficult to catch all the horses running loose already, but we can still encourage plug-in developers to not do this in the future. Sascha wrote: "(Another annoying lock-in problem of a plug-in system that is open too wide ... - 2¢)" I was thinking about this the other day. One side effect of having such a flexible plug-in architecture is that just about every public interface in the program is exposed to plug-in developers. While this is extremely powerful, it also seems to lead to some pretty ugly interdependencies. I'm beginning to realize that is why so many mock objects are required to write JUnit tests for some of my OpenJUMP code. Everything is intertwined. Perhaps this is why Eclipse uses the concept of "extension points". I guess they were trying to narrow down the access points for plug-ins. Pluggable design is a great thing, but it really seems to mess with some other programming concepts like modularity and refactoring. Still, I think we can limits the effects of this by coming up with some guidelines to help plug-in developers. Sascha wrote: "BTW: I'm not sure if the CoordinateSequence idea will save a lot of memory. It may be right that the data is packed more tightly and the object overhead would be trimmed, but we might also see a lot of temporal garbage when using the data. JTS is not 'streamlined' with this idea so I suspect a lot of internal 'new Coordinate(..)'s when we're transforming the data (e.g rendering). AFAIK the packed versions of CoordinateSequence have a SoftReference cache mechanism for toArray() inside. I don't know how often this is really called, but objects hanging at SoftReference tombstones are kept quiet long by the GC. ... Just as a hint. Evaluating this maybe connected with some work and at the end it might turn out that there will be probably little to no gain." I think that this would be good material for the JTS list. Sascha wrote: "If we further take into account that only large data sets with a lot of shared vertices will profit from this I would recommend to think about the ratio effort/work." Yup, this might be only be worth it for large data sets. I wonder if you could do this by making a special implementation of the FeatureCache like I am doing with the FeatureCache. The Sunburned Surveyor On 6/26/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > > Sunburned Surveyor schrieb: > > [...] > > Sascha's idea about eliminating duplicate coordinate objects in large > > polygon layers and linesting layers is interesting. I have some > > questions for him on that, but I will put them in another thread so > > things don't get so confusing. > > [...] > > If they are worthy a new thread ... > > > [...] > > I'm sorry if I confused things. I didn't say we should implement > > Sascha's idea, just that I thought it was interesting. :] > > For now: We have side effects. Martin has at least one > plug-in which modifies coordinates in place, > Michaël is modifying z-values in place, Larry stated > that the ISA tools are full of coord.x = ... stuff. > My initial question was asking for side effects so I > see these facts as show stoppers for the idea. > > It would be nice to have a "immutable policy" for coords and > geometries but we'll have to catch all the horses first. > (Another annoying lock-in problem of a plug-in system > that is open too wide ... - 2¢) > > BTW: I'm not sure if the CoordinateSequence idea will save a > lot of memory. It may be right that the data is packed more > tightly and the object overhead would be trimmed, but we > might also see a lot of temporal garbage when using the data. > JTS is not 'streamlined' with this idea so I suspect a lot > of internal 'new Coordinate(..)'s when we're transforming the data > (e.g rendering). AFAIK the packed versions of CoordinateSequence > have a SoftReference cache mechanism for toArray() inside. > I don't know how often this is really called, but objects hanging > at SoftReference tombstones are kept quiet long by the GC. > ... Just as a hint. Evaluating this maybe connected with > some work and at the end it might turn out that there > will be probably little to no gain. > > If we further take into account that only large data sets > with a lot of shared vertices will profit from this > I would recommend to think about the ratio effort/work. > > Regards, > Sascha > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
