Re: [convert] a different approach...
Saturday, November 27, 2004, 1:46:28 PM, Matt Sgarlata wrote: > Actually I'm taking on every problem that Convert was planning to take on, > so short[] -> int[] is one type of conversion Morph will be able to perform. Uups, sorry for getting things wrong. Sounds all the more interesting. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] a different approach...
Thursday, November 18, 2004, 5:57:48 AM, Matt Sgarlata wrote: > I haven't been on the list a while but I saw your posts earlier > this month. I too, like Ron, spent some time developing my own > approach to the goals of the commons-convert project. I have some > code started out that isn't incredibly well documented, but all the > ideas are there. Below is a summary of my approach. The code is > available at the URL below under the Apache 2.0 license. I've taken a quick look at your description and the source, which looks quite promising. Correct me if I am getting things wrong, but I think we try to solve different problems, which is acutally a good thing (as they might even complement each other). If I get things right, you try to provide a framework for passing "bean like" structures around, and convert them to their various representations, as every library provides its own. My focus is on trying to provide a "generic" conversion framework, with primary focus on the type. Eg, some libraries like to use "int," others prefer "short," which makes not much of a difference if all values are, say, between 0 and 1000. While this conversion is quite simple for some types, it can be cumbersome for others, eg if you got a short[], but the library prefers an int[]. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Type Conversion Library
Thursday, November 11, 2004, 6:54:44 PM, Henri Yandell wrote: > You can do what you want with your own copy of any code you send in to [snip] Thanks for the info. > recently stopped using it and am building again from scratch. I am looking forward to seeing your approach. > My suggestion is that you release your library on your own and see how > it goes. As long as it's licence compatible (simplest being to use > ASL-2), we'll be very interested in seeing how it goes and probably > all be interested in becoming users of it. Yup, I'll do that. Thanks again, Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Type Conversion Library
Wednesday, November 10, 2004, 11:56:04 PM, robert burrell donkin wrote: > On 10 Nov 2004, at 22:46, Stephen Colebourne wrote: >> This is a legal question, and most of us aren't very good at those ;-( >> >> I believe that if your new work is derived directly from the original >> source >> you gave to the ASF, and is not derived from any later additions made >> whilst >> part of [convert], then the code is still just yours to do as your >> wish. But >> IANAL. > this is also my understanding (again, though, IANAL). if this isn't > good enough for you, then probably general at jakarta would be a better > place to raise this issue. maybe a member or henri will be able to give > you a more definitive answer... > of course, the derived contributions are also be built on providing > that you abide by the terms of the ASL2.0 (which aren't very onerous). Thanks for your responses. I'm planning to distribute it under der Apache License as well, so I hope there are little or no issues. What I don't know is if you guys would be interested in the library as part of commons. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Type Conversion Library
Wednesday, November 10, 2004, 8:15:51 PM, Kris Nuttycombe wrote: > I'm certainly interested in type conversion problems. Are you working > with the existing commons-convert project in the sandbox? No, it's something different that currently just lives on my hard disk. The code is somewhat messy, and may be of little use for others right now. But I'm about to start working on the documentation. The approach is nothing really fancy. It contains a simple type system, to model primitives, classes and parametric types, a graph to "draw" the conversions and a lookup (currently Dijkstra's shortest path algorithm) to find a conversion path. Once I've got the basic documentation in place I'll put it up somewhere, and gladly drop you a note. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[convert] Type Conversion Library
Some time ago, I came to this group with a proposal for a generic type
conversion library. As a refresher, it is a graph based solution,
where you just drop in your converters and the library will try to
figure out a possible path.
Some example conversions that are working include
- String -> Integer (via String -> Long -> Integer path)
- u[] -> v[], given the library knows how to convert u -> v (eg, you
can simple say
final byte[] bytes = converter.convert(new int[]{1,2,3},
Types.findType("byte[]"));
- u[] -> List, given the library knows how to convert u -> v
The library's primary goal is to be generic. Quite useful for rapid
prototyping, or generic conversion (when you don't quite know the input
or output type).
Since you guys weren't too eager on my initial proposal, I don't
expect that you are now - which is ok, really.
But the library may or may not contain thoughts from our initial
discussion, so I'd like to make sure that it is ok that I publish the
library at my discretion.
Thanks,
Ron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Initial ideas (was: conversion with default values)
OH> I had a look at your ideas and now I have a few questions and remarks.
Great!
OH> At first let me say that I like the idea of using a graph representation
[...]
I definitely agree. Things get a lot easier that way. Besides, we
could even support a special debug mode, where we plug in a graph renderer
and thereby provide an image of the registered converters (just like
the ones in the document I posted, and had drawn by hand). If a
conversion succeeds we could provide an image of the path chosen (may
be useful if an unexpected result pops up.)
OH> The idea to use a separate lookup class seems interesting, too. But
OH> after thinking a while about it I am not sure if this really helps
[...]
OH> registry. So this would imply that for different lookup classes other
OH> data has to be stored in the registry. Can this be handled in a generic
OH> way or wouldn't it be better to leave the lookup mechanism in the
OH> registry and use different registry implementations?
In my current line of thought the registry and lookup are quite
tightly coupled, but serve different purposes. The Registry is just a
plain storage, whereas the Lookup provides the algorithm(s?) to work
on them. For example, the ClassConverterRegistry provides/should
provide all Converters the Java language uses for a class (inheritance,
toString()). But then again, something simpler like a Set or List
might be better suited for that.
OH> 2. A lookup might be expensive, especially if a search in a complex
OH> graph has to be performed. So it might make sense to implement some
OH> caching functionality. I am not sure if this can be done efficiently in
OH> a lookup class implementation because in your example code always a new
OH> lookup instance is created (though I might miss something here).
You are right, the lookup should definitely be cached, but I didn't go
that far in my implementation. I guess there are a number of things
we can do, though I haven't thought them through yet. First, we could
build a single graph for a Lookup and incrementally extend it (there
may be times when it has to be rebuild, eg when a converter is
removed, or the graph gets too big). Then, we could cache some paths,
in case they are reused. The shortest path algorithm provides the
shortest path to all destinations from a source, so this computation
may somehow be reused, too.
OH> The approach with the Types handles inheritence, but does it cover all
OH> cases? I am not sure if the following use case could be handled: imagine
OH> a user has the classes A, B, C, and D with B and C extending A. Then
OH> there are special conversion implementations for A->D and B->D. If now
OH> an object of class C is provided, will then the A->D conversion be used?
OH> With other words: inheritence in direction towards the base classes is
OH> surely supported, but can derived classes be handled without extra means?
Yes. In my model, everything is a conversion, even inheritance,
implementation of an interface, or the String conversion (toString) of
any object. In your example, a chained converter would be build, to
provide the conversion C -> A -> D. In the prototype, this is done via
extension of the graph with the converters of the class C (see
addTypeConverters for both the source and destination type). So, in
the beginning you only have the converter A -> D, but as you ask for a
conversion of an object of type C, the conversion C -> A is added.
public ExtendedConverter lookup(final Type sourceType,
final Type destinationType) throws NoSuchConversionException {
addTypeConverters(graph, sourceType);
addTypeConverters(graph, destinationType);
return new
ChainedExtendedConverter(getConvertersForPath(getShortestPath(sourceType,
destinationType)));
}
OH> What about structural conversions, e.g. a String[] to a int[] or a
OH> collection of Integers to a byte[]? Where would these conversions take
OH> place? (I think this is slightly different from constructing a chain of
OH> conversions because here a base conversion has to be performed multiple
OH> times.)
I started to think about that too, but postponed that for a version 2
of convert. Here is how far I got:
I think it's better to think about String[] or int[] as a parametric
type, like Array or Array. That way, it will be easier
to think about conversions as Array to List (aside
from supporting Java 1.5). Now, a converter needs to worry about the
outer structure (Array -> List) and the meat (int -> Integer) (this
would apply for other structures too, eg List -> Set). I could
imagine an implementation like this:
public class ListToSetConverter extends AbstractConverter {
final Type srcParam, destParam;
public ListToSetConverter(final Type srcParam, final Type destParam) {
this.srcParam = srcParam;
this.destParam = destParam;
}
public Type getSourceType() {
return Types.parse("List<*>", srcParam);
}
public Type getDestinationType() {
Re: [convert] Use cases not currently covered
LA> 1) The actual conversion logic should be implemented in small chunks,
LA> inside the most primitive, bare code-container, interface :
LA> public interface Conversion {
LA> public Object convert(Object value) throws Exception;
LA> }
I agree that the interface should be small, but I am not too sure
about the Exception. Throw-everything forces the caller to
Catch-everything. Maybe a more specific Exception, like
ConversionFailedException, is sufficient.
LA> One implementation should do one simple, well-specified conversion,
[...]
Agreed.
LA> 2) There should be multiple manager classes to implementing distinct
LA> policies for choosing a Conversion. ConversionRegistry will be one
LA> such manager. Other managers may build transitive Conversion chains,
LA> handle inheritance, provide accessors for primitives, etc. Clients
LA> will work with managers, never Conversions themselves. Managers will
LA> wrap exceptions thrown by Conversions in ConversionExceptions. There
LA> is no one interface that could sum up all possible managers.
I also agree very much, but I'd like to see an intermediate structure
to store converters (which I have presented recently as
ConverterRegistry). The managers (ConverterLookup, or however it may
be named) would provide the algorithm to work on the converters.
[snip]
I like the ideas you presented quite a bit. The one thing I don't
understand is how you decide which converter to take. In other words,
why don't you need the input/output type information?
If you want, check out my ideas at
http://www.rblasch.org/convert/convert-docs.zip
http://www.rblasch.org/convert/convert-proto2.zip
Ron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Initial ideas (was: conversion with default values)
>> RB> Don't know if the images made it to the list, so you'd better get >> RB> http://www.rblasch.org/convert/convert-docs.zip >> A snapshot of my prototype is also available at >> http://www.rblasch.org/convert/convert-proto2.zip SC> The complex conversions involving Type I didn't manage to grok, but maybe I SC> will if more awake. I'd like to keep [convert] simple if possible, maybe you SC> could have a think about whether the %age match stuff in the CVS is of any SC> use. If I understood it correctly, the percentage is used to provide some means select the "best" converter (or chain of converters). The weight in the edges of the graph I used serve the same purpose. I have used only the value "1", but any other positive value will do. The shortest path algorithm then searches for the converters with a minimal sum. Say, you have got the converters Integer -(80)-> Byte Byte -(80)-> Boolean To get from Integer to Boolean you have a weight of 160, which is the shortest path (the only one). If you add the Integer -(60)-> Boolean converter, it would be chosen because its weight would be 60. The prototype currently provides no way to set the weights, but would be easy to add. I think the percentage stuff is useful, though I'd call (and maybe use) it a little different, as I got used to to the term "weight" from graph theory. SC> Stephen SC> PS: I'm on holiday for a week from Wednesday ;-) Enjoy your holidays! :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Initial ideas (was: conversion with default values)
SC>>> Basically the sooner you can make available SC>>> ideas/designs/code the more it SC>>> can be talked about ;-) RB>> Point taken. Please find attached a summary of my thoughts (well, not RB>> all of them; just those related to convert). RB> Don't know if the images made it to the list, so you'd better get RB> http://www.rblasch.org/convert/convert-docs.zip A snapshot of my prototype is also available at http://www.rblasch.org/convert/convert-proto2.zip The code is A Real Mess and may cause brain damage. You have been warned. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Initial ideas (was: conversion with default values)
RB> Sunday, March 21, 2004, 2:59:12 AM, you wrote: SC>> Basically the sooner you can make available SC>> ideas/designs/code the more it SC>> can be talked about ;-) RB> Point taken. Please find attached a summary of my thoughts (well, not RB> all of them; just those related to convert). Don't know if the images made it to the list, so you'd better get http://www.rblasch.org/convert/convert-docs.zip Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Initial ideas (was: conversion with default values)
Sunday, March 21, 2004, 2:59:12 AM, you wrote: SC> Basically the sooner you can make available ideas/designs/code the more it SC> can be talked about ;-) Point taken. Please find attached a summary of my thoughts (well, not all of them; just those related to convert). Ron http://www.w3.org/1999/XSL/Transform";> http://www.w3.org/2001/XMLSchema-instance";> think.xml Description: application/xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] conversion with default values
Hello Stephen, Saturday, March 20, 2004, 9:54:53 PM, you wrote: SC> One thing I found when I started at Commons is that things often take longer SC> than planned ;-) Just as anything that's related to software. ;-) SC> Anyway, what you can do is to join the mailing list, if you haven't already SC> ([EMAIL PROTECTED], emails prefixed by [convert]) . Then submit SC> your code as a patch to Bugzilla if you can (is it yours to donate to SC> Apache?). I am already subscribed to commons-dev. The prototype is based on the old convert code, which I used as a starting point. The code, apart from the old convert stuff and a heavily modified shortest path lookup implementation (guess I'd still better ask the author for permission before submitting it), is mine. SC> Everyone should also take a good look at the new website and the new code, SC> which I'm hoping will be the basis for things going forward. Would it be better if, instead of submitting my old proto, I'd provide a xdocs where I put together all of the stuff I had in mind? Ron -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] conversion with default values
Hello Stephen, Saturday, March 20, 2004, 2:13:21 AM, you wrote: >> >to Integer. The trick is then to design a combination engine to allow >> >StringBuffer to Integer by combining StringBuffer to String plus String >> >to Integer. >> Sounds interesting. Do you have already concrete ideas how such a >> combination engine would look like? I have thought about converters >> working together in a kind of chain, too, e.g. for String to Integer ... >> These are all slightly different use cases that should be supported by >> such an engine. What do you think? SC> Ron Blasch had some ideas on how this might work. I've cced to see if he SC> wants to comment. Thanks Stephen. I'd really like to move convert forward, but received very litte feedback to my last posts, so I thought nobody cared too much. I have: - some ideas how the convert lib should look, which I think would also solve the problems mentioned in this thread - a working prototype of most of my ideas - lots of enthusiasm to move convert forward Stephen, how should we proceed? Would it be worth, and possible, for me to get commit access? Or should I keep sending things to you and/or the list? Ron -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new project proposal: Type Conversion Library
Tuesday, January 20, 2004, 6:05:20 PM, you wrote:
>>Again, such values exist in our (mostly internal) configuration files.
SY> OK, I see your use-cases.
>>Besides, I'd like to see the constructor-valueOf-asList-toArray stuff
>>cleaned up a bit by a common interface.
SY> I don't share that desire. I think it's neat that each class knows (and
SY> exposes) what conversions it can and can't do. It's nice encapsulation.
SY> If you want a central converter, suit yourself ;)
Just firing up random thoughts here (drilled down into my head a few
inches), but suppose you could use your private TypeConverter, then
you could
1) Again, provide a converter for configurations from String,
ConfigurationEntry, or whatever, to the user's desired type. Say
foo.properties:
component.factory=some.package.with.Factory
Class factoryClass =
(Class)getConfiguration().getConvertedEntry("component.factory", Class.class);
or even, for the more adventurous
/* String - Class(forName) - Object(newInstance) */
Factory f =
(Factory)getConfiguration.getConvertedEntry("component.factory", Object.class);
2) An object renderer, to convert types to a Strings (if everybody
would just implement toString...), maybe with locale support (if you want
to).
Even if you want to keep the conversions in the class, it would, IMHO,
make a nice helper for them.
Ron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re[4]: new project proposal: Type Conversion Library
Tuesday, January 20, 2004, 2:49:17 PM, you wrote:
SY> I'm still missing the "why" i.e. why do you want this package? What are
SY> the use-cases? Technical questions aside, I'd like to know the
SY> motivation for this project ;)
I have a user configuration (kinda like java.util.Properties) that
contains Strings, and a Seconds class whose sole contructor takes a
long. In my opinion, the Seconds class should not need to know about
(most?) useful conversions, because often you can't. Eg, the only way
I know of to convert a Byte to an Integer is
Byte b = new Byte(10);
...
Integer i = new Integer(b.intValue());
(Should the Integer class have a constructor that takes a Number?)
Another thought that pops up is the conversion of String("3,5,2") to
an int[], or a List that contains Integers.
Maybe, something like
int[] foo = (int[]) TypeConverter.convert("3,5,2".split(","), int[].class);
or
List /* of Integer */ bar = (List) TypeConverter.convert("3,5,2".split(","),
/*container type*/List.class, /*element type*/Integer.class);
Again, such values exist in our (mostly internal) configuration files.
Besides, I'd like to see the constructor-valueOf-asList-toArray stuff cleaned
up a bit by a common interface.
Ron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: new project proposal: Type Conversion Library
Tuesday, January 20, 2004, 12:17:04 AM, you wrote: HY> Yep, [convert] exists in the sandbox and I've been moving forward with it HY> in my usual way, which means I find a way to use it in some non-apache HY> project of mine and just see how it goes. I've got it attached to two HY> projects, but it's not being used in anger in them yet. HY> The code is based on the beanutils code, with a new lookup mechanism. I'm HY> happy to mentor any further work on it, so you won't get abandoned without HY> the ability to add patches etc. HY> On Mon, 19 Jan 2004, robert burrell donkin wrote: >> here are some urls: >> >> http://jakarta.apache.org/commons/volunteering.html >> http://jakarta.apache.org/commons/patches.html >> http://jakarta.apache.org/site/getinvolved.html >> >> but there's quite a lot else on the web site and the wiki if you're >> willing to look hard enough. Thanks a lot for the pointers to convert and how to get involved. I glanced over convert and it seems the right place to start. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: new project proposal: Type Conversion Library
Monday, January 19, 2004, 11:34:36 PM, you wrote: SK> On Tue, 2004-01-20 at 11:07, Ron Blaschke wrote: >> I am posting this here because I think commons would be the >> right place to put such a library. Please tell me if it's not. >> >> The idea is to allow conversion for (almost?) any object into another. >> I'd like to see code such as this working: SK> Have you looked at ConvertUtils in the BeanUtils library yet? SK> http://jakarta.apache.org/commons/beanutils/api/index.html SK> It does pretty much what you describe here. You may wish to look at SK> that, then send a mail describing how your ideas differ from what is SK> already there.. In ConvertUtils, the conversion relies a lot on JDK implementations, which is quite "relaxed." Eg, Integer(128) -| Byte(-128), Double(1.3d) -| Integer(1), etc. I'd like to see a more configurable approach, for example: strict: "1.23" -| Integer ... not possible, raise Exception relaxed: "1.23" -| Integer(1) ... seems ok or: strict: Integer(128) -| Byte... no way! raise Exception relaxed: Integer(128) -| Byte(127) ... close enough The converter should enable transitive conversions, that is if one converter knows about A to B conversion, and another from B to C, both together should know about A to C. In the Seconds example, it would suffice for the user supplied Seconds converter to know about Integers to allow conversion from String via Integer to Second. In ConvertUtil, the converter must know about all possible conversions (well, most of it is handed off to Java, which is ok, but I'd rather not go down that lane.) That's all that is on top of my head. For more, I'd have to dig a day or so. :-) Ron -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new project proposal: Type Conversion Library
I am posting this here because I think commons would be the
right place to put such a library. Please tell me if it's not.
The idea is to allow conversion for (almost?) any object into another.
I'd like to see code such as this working:
Object a = new Integer(10);
Object b = "120";
assertEquals(new Integer(10),
TypeConverter.convert(a, Integer.class));
assertEquals(new Integer(120),
TypeConverter.convert(b, Integer.class));
Of course, it should be extensible, and maybe allow for transitive
conversions, eg
class Seconds extends Time {}
TypeConverter.registerConverter(Integer.class, Seconds.class, /* some
converter object here */);
assertEquals(new Seconds(25), TypeConverter.convert("25",
Seconds.class); /* done via String -> Integer -> Seconds conversion */
Or add some constraint checking:
System.out.println(new Integer(128).byteValue()); /* prints -128; is
that what you wanted? */
Currently, I have only my ideas to donate (ie, no code yet), and have
not previously contributed to jakarta, so any guidance is appreciated.
Thanks,
Ron
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
