Re: [convert] Designs [was Another use case]

[Stephen Colebourne <sc...@btopenworld.com>]

I have just checked in a load of new commits in the convert2 subpackages.
Essentially there are now two convert codebases in CVS, Henri committed the
first based on [beanutils] IIRC, whereas I've developed the second. An
external review would be good. If you could take a look at both and see what
you like that would be great ;-)

Once one is picked, we can then get on and add more converters and tests,
and then maybe look to a release. I'd like an early promote and release if I
can manage it.

Stephen
[
Notes about convert2 package:
System is bean based - different applications can have different converters.
Each individual conversion is an implementation of a simple interface
Conversion.
The combination of a group of Conversions is a Converter.
A ConversionFactory allows Conversions to be dynamically created.
Main conversion registry is fully synchronized (as double check locking
broken).
]

----- Original Message -----
From: "Oliver Heger" <Ol...@t-online.de>
> Stephen Colebourne wrote:
> [snip]
>
> >>What do you think of this approach? If I provided some patches for this
> >>feature, would somebody be willing to apply them?
> >>
> >>
> >At present, I reckon [convert] is not advanced enough for this
discussion.
> >But if you want to help progress the underlying project then that would
be
> >great.
> >
> >
> Okay, what can I do?
>
> Oliver



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [convert] Designs [was Another use case]

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Oliver Heger" <Ol...@t-online.de>
> In convert2 I like the Converter class, which is an additional
> encapsulation of a registry.
This level seems like a necessity in a design to group the individual
conversions into one place.

> On the other hand I have some problems
> to see the benefits of the convert2.ConversionFactory: Because a factory
> is used only once to obtain a Conversion for a to/from class
> combination, there are not many advantages over using a Conversion
> object directly
The ConversionFactory allows for inheritance and performance. The
ObjectToString factory already allows any object to be converted to a
String. And as the individual calls are made, the conversion objects build
up to avoid bothering the factory.

> (I think it would be more flexible if the Conversion
> returned by a factory would not be stored; then a factory could return
> different objects based on the actual value).
The Conversion should not be dependent on the value, just the types. (Do you
have a use case where this isn't true?)

> In the available implementations I would somehow
> try to refactor out the handling of default values, maybe as a kind of
> decorator converter.
I had this thought too, but haven't done anything about it yet. Also, locale
handling may be something to consider. Thats partly why I added the
reference to the converter to the Conversion.convert() method.

> What I miss in both approaches is a more intuitive setup mechanism, a
> simple way to construct a registry from available converter
> implementations, though I don't have a concrete idea how to improve this
> either. Would it make sense to construct a default registry from a
> configuration file? Is it perhaps possible to use [discovery] to find
> converter implementations (I don't know this project very good).
Personally, I dislike config files in a project like this. Notably,
everybody wants to do config differently. Maybe by xml, or properties or
beans or jndi. I want to keep that separate from [convert].

> Another suggestion: Depending on the actual use case it might make sense
> if a failing conversion throws a checked exception rather than a runtime
> exception, e.g. when used to validate user input. So it could be useful
> to add methods that throw an exception and let the client choose.
I have to disagree on this. I no longer believe that simply because
something is checked means it gets better or more secure exception handling.


I'd like to expand the convert2 codebase if possible, pulling in ideas from
convert1. The main tricky areas are default values and locales. If you'd
like to suggest some patches, I'll have a look.

Stephen

> Stephen Colebourne wrote:
>
> >I have just checked in a load of new commits in the convert2 subpackages.
> >Essentially there are now two convert codebases in CVS, Henri committed
the
> >first based on [beanutils] IIRC, whereas I've developed the second. An
> >external review would be good. If you could take a look at both and see
what
> >you like that would be great ;-)
> >
> >Once one is picked, we can then get on and add more converters and tests,
> >and then maybe look to a release. I'd like an early promote and release
if I
> >can manage it.
> >
> >Stephen
> >[
> >Notes about convert2 package:
> >System is bean based - different applications can have different
converters.
> >Each individual conversion is an implementation of a simple interface
> >Conversion.
> >The combination of a group of Conversions is a Converter.
> >A ConversionFactory allows Conversions to be dynamically created.
> >Main conversion registry is fully synchronized (as double check locking
> >broken).
> >]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [convert] Designs [was Another use case]

[Oliver Heger <Ol...@t-online.de>]

Stephen,

I had a first look at both code bases. From the underlying concepts both 
seem to be very similar: they both have a basic interface describing a 
conversion/converter, factories for converters and a registry mechanism. 
This said it is quite hard to judge, which implementation should be 
preferred.

In convert2 I like the Converter class, which is an additional 
encapsulation of a registry. From a semantic point of view it is 
certainly better to use a "Converter" for conversions than a 
"ConvertRegistry" as in convert1. On the other hand I have some problems 
to see the benefits of the convert2.ConversionFactory: Because a factory 
is used only once to obtain a Conversion for a to/from class 
combination, there are not many advantages over using a Conversion 
object directly (I think it would be more flexible if the Conversion 
returned by a factory would not be stored; then a factory could return 
different objects based on the actual value). (And one minor detail: I 
think the first method in ConvertUtils should be named convert() and 
perform a default conversion rather than a String conversion.)

The convert1 package has the advantage that it partly deals with 
inheritence, which can be useful. Though when looking at the code I am 
not sure that the current implementation will work. Because the 
Converter interface is very simple it seems to be easier to implement 
concrete converters. In the available implementations I would somehow 
try to refactor out the handling of default values, maybe as a kind of 
decorator converter.

What I miss in both approaches is a more intuitive setup mechanism, a 
simple way to construct a registry from available converter 
implementations, though I don't have a concrete idea how to improve this 
either. Would it make sense to construct a default registry from a 
configuration file? Is it perhaps possible to use [discovery] to find 
converter implementations (I don't know this project very good).

Another suggestion: Depending on the actual use case it might make sense 
if a failing conversion throws a checked exception rather than a runtime 
exception, e.g. when used to validate user input. So it could be useful 
to add methods that throw an exception and let the client choose.

Oliver

Stephen Colebourne wrote:

>I have just checked in a load of new commits in the convert2 subpackages.
>Essentially there are now two convert codebases in CVS, Henri committed the
>first based on [beanutils] IIRC, whereas I've developed the second. An
>external review would be good. If you could take a look at both and see what
>you like that would be great ;-)
>
>Once one is picked, we can then get on and add more converters and tests,
>and then maybe look to a release. I'd like an early promote and release if I
>can manage it.
>
>Stephen
>[
>Notes about convert2 package:
>System is bean based - different applications can have different converters.
>Each individual conversion is an implementation of a simple interface
>Conversion.
>The combination of a group of Conversions is a Converter.
>A ConversionFactory allows Conversions to be dynamically created.
>Main conversion registry is fully synchronized (as double check locking
>broken).
>]
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org