commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [convert] Designs [was Another use case]
Date Sun, 07 Mar 2004 20:48:02 GMT
From: "Oliver Heger" <Oliver.Heger@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


Mime
View raw message