commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [convert] Almost there
Date Sat, 14 Feb 2004 13:01:46 GMT
I have checked into CVS a variant high level API which I'd like to get close
to if possible. It doesn't mandate any real implementation so hopefully we
can work to it or something like it.

(It involves a static method utils class that is immutable, and a
ConverterSet class that can be created with different setups of converters)

Your suggestion of a Type class is interesting. It might work, but it might
also be overkill. Perhaps if the class is effectively needed anyway for
storage in some map, then it makes little odds. The main questions will be
performance and object creation.

Maybe to prevent overkill, we just need a testcase to cover the conversions
we want ;-)


----- Original Message -----
From: "Ronald Blaschke" <>
> I've been busy with other work, still found some time to think about
> convert.  In my last mail I wrote about unifying everything into
> simple converters and a shortest path lookup in a directed weighted
> graph.
> This includes (or might include):
> - user defined conversions
> - inheritance, or more generally casting conversion (cf Java Language
>     Specification 5.5 Casting Conversion)
>     Eg, Integer[] can be casted to Object[], but is not a superclass
>     of it (Integer[] isa [class java.lang.Object, interface
>     java.lang.Cloneable, interface])
> - String conversion (cf Java Language Specification String
>     Conversion: "Any type may be converted to type String by string
>     conversion.")
>     by adding an Object -> String converter to the graph
> - others
> Now, the problem I came across was where to put the converters.  I've
> come up with a neat idea: Don't use java.lang.Class to represent the
> type, but a Type, which knows about a bunch of conversions that are
> related to the type.
> public interface Type {
>     String getName();
>     ConverterRegistry getConverters();
> }
> I haven't (yet) figured out which conversions a type should provide,
> but see below for a quick start.  We may (or may not) add (or remove)
> others as we go along.
> For example: System.out.println(new
> [java.lang.Object -> java.lang.String,       /* String conversion */
>  java.lang.Integer -> java.lang.Number,      /* extends */
>  java.lang.Integer -> java.lang.Comparable,  /* implements */
>  java.lang.Number -> java.lang.Object,       /* extends */
>  java.lang.Number ->]   /* implements */
> I've already implemented most of it, but it's not documented.  Very
> simple support for primitive array types is included.
> Also, the returned values should be considered read-only, and
> documented as such (maybe someone will come up with a copy-converter
> implementation. :-)
> Some more thoughts:
> - IMHO, the solution looks nice, but uses a fair amount of memory and
>   CPU (graph, shortest path, ...).  Can we live with that?
> - I have added a small shortest path implementation, but we may want
>   to plug in some other implementation that can plot and layout the
>   graph to an Image (eg jung or openjgraph), which would be great for
>   debugging :-)
> If you agree to the global design (Types as vertices, Converters as
> edges, everything in a graph) I'll document the implementation and get
> back to you guys.  Then we can decide what details we keep, and what
> we throw out (I may have added too much).  Then we can optimize the
> implementation (currently, for every conversion a new graph is
> created) and add any standard converters the three of us need.
> Ron
> --

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message