Gabriel Roldan ha scritto: > Hi Andrea, > > the converter function is a really good idea, and just what I was > thinking about when reading over the problem. One thing though, is that > the way it is exposed seems like too java centric, perhaps it would be > nice to create a function per primitive type (say, asInt(), asDouble(), > etc), and avoid the java class names as argument? It is just because > having a function tied to the underlying programming language in the > interoperability protocol seems a bit odd.
I would not be too concerned about the "interoperability" part, OGC gave filter functions a syntax level interoperability, but since they did not specify a list of well known ones, the interoperability potential ends there. My suggestion of being able to specify int/double/long/... (primitives) was actually a way to make the converting function more amenable to the normal user. Having functions like asInt/asDouble is better from a user point of view, but requires writing a number of functions, and does not leave out the need for a generic convert function, since the specific ones cannot cover every case. But instead of making a converter that does handle java.lang and primitive names to turn them into classes, I can as well roll a handful of functions that actually use the generic one as their superclass, and roll: asInteger asLong asFloat asDouble asBoolean asString Opinions? Cheers Andrea ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
