Hi Bart, On Wednesday 23 July 2008, you wrote: > I am using the transform function of OpenLayers, which in its turn calls > proj4js, should it change the transformed property for all the points in a > geometry in your opinion? That does not seem effective does it?
Like Christopher said, you shouldn't have any reason to transform your coordinates twice. But, if you are like me and your application allows the user to switch projections multiple times by using a combobox, then your application may apply transformation more than once on your objects. Or you should always keep a copy of the geometries in the original projection to avoid approximation errors. On one hand, proj4j is sparing some memory (I'm the first one to encourage that, especially with a garbage collector in the way) by replacing the values in the passed object, but, on the other hand, it adds a field to this object eating some more memory. If it's for avoid some bugs, then it's a good idea, but it's done wrong. A lib should not ignore a API call because it thinks its a bug. Then how can the programmer notice he has something wrong in his code? Proj4j is not OpenLayers. So maybe it's not the good place to discuss this problem here. If we broaden the discussion, the javascript world has IMHO way too much places where the errors are silent and the input are assumed to be correct (defined, of the good type and consistent) and never checked. I think the debug version of the libs (OpenLayers, Ext, proj4j, ...) should have extra code checking the consitency and reporting all errors (throwing exceptions). For example, a constructor should check that all the mandatory settings are set, of the good type and consistent. That would help the developper to find errors as soon as possible. This code could be tagged and be removed by the scripts building the compressed/merged release version to avoid performance impacts. This kind of code could also check and document the expected state of an object at the start of a method. This technique is called "Design by Contract" [1]. An excellent article [2] from my friend Adrian will explain the concept better than me. CU [1] http://en.wikipedia.org/wiki/Design_by_Contract [2] http://kosmaczewski.net/2007/08/23/design-by-contract/ _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
