You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/02/14 14:01:46 UTC
Re: [convert] Almost there
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 ;-)
Stephen
----- Original Message -----
From: "Ronald Blaschke" <rb...@web.de>
> 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 java.io.Serializable])
>
> - String conversion (cf Java Language Specification 15.18.1.1 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
ClassConverterRegistry(Integer.class));
> [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 -> java.io.Serializable] /* 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] Almost there
Posted by Ron Blaschke <ma...@rblasch.org>.
Hello Stephen,
Saturday, February 14, 2004, 2:01:46 PM, you wrote:
SC> I have checked into CVS a variant high level API which I'd like to get close
SC> to if possible. It doesn't mandate any real implementation so hopefully we
SC> can work to it or something like it.
SC> (It involves a static method utils class that is immutable, and a
SC> ConverterSet class that can be created with different setups of converters)
A question:
- How would the ConverterFactory be used? Do we need it?
And some additions:
- We may want to come up with some better names. ConverterSet sounds
too much like a java.util.Set with some extras.
- We should provide an empty ConverterSet and a ConverterSet which is
pre-filled with the standard converters.
- I don't think we need the specific ToFooConverter, though we might
want to provide an API for it in ConvertUtils, and use boxing/unboxing
for the Converters
- I'd like to associate some metadata with the converter, at least the
source and destination type (class), and maybe some other we come up
with, eg
public interface Converter {
// metadata
Class getSourceClass();
Class getDestinationClass();
// your favorite metadata here...
Object convert(Object value) throws ConversionFailedException;
}
- We should provide an AbstractConverter, which implements some checking
on the input and output.
- I'd like some storage via which converters can be looked up
(easily), eg
public interface ConverterRegistry
extends Set /* but not sure about that */ {
Converter lookup(Class sourceType, Class destinationType) throws NoSuchConversionException;
}
- We should also nail down the requirements of the lookup. Here is my
suggestion:
- Cast conversion (including inheritance) should be honored
- No transitive lookup
- When no conversion is found a NoSuchConversionException is thrown,
when more than one conversion is found a AmbiguousConversionException
is thrown
- We should add add/remove methods for converters to ConverterSet,
instead of granting access to the registry.
SC> Your suggestion of a Type class is interesting. It might work, but it might
SC> also be overkill. Perhaps if the class is effectively needed anyway for
SC> storage in some map, then it makes little odds. The main questions will be
SC> performance and object creation.
SC> Maybe to prevent overkill, we just need a testcase to cover the conversions
SC> we want ;-)
After pondering about it for while, I guess we are better off for most
cases with the simple approach (cast conversion, no transitive
lookup).
The good news (at least for me :-)) is that with the Converter and
some storage, as mentioned above, it's quite easy to build the
extended stuff I am thinking about, reusing the converters.
That way, we can provide two implementations, where you only pay what
you ask for. :-)
Ron
SC> ----- Original Message -----
SC> From: "Ronald Blaschke" <rb...@web.de>
>> 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 java.io.Serializable])
>>
>> - String conversion (cf Java Language Specification 15.18.1.1 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
SC> ClassConverterRegistry(Integer.class));
>> [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 -> java.io.Serializable] /* 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org