Re: [picocontainer-dev] ConfigParameterTestCase / ConfigParameter

Well I have the following ....

    private static final Map<Class, Converter> stringConverters = new  
HashMap<Class, Converter>();
     static {
         stringConverters.put(Integer.class, new Converter() {
             public Object convert(String paramValue) {
                 return Integer.valueOf(paramValue);
             }
         });
         stringConverters.put(File.class, new Converter() {
             public Object convert(String paramValue) {
                 return new File(paramValue);
             }
         });
         stringConverters.put(Double.class, new Converter() {
             public Object convert(String paramValue) {
                 return Double.valueOf(paramValue);
             }
         });
         stringConverters.put(Boolean.class, new Converter() {
             public Object convert(String paramValue) {
                 return Boolean.valueOf(paramValue);
             }
         });
         stringConverters.put(Long.class, new Converter() {
             public Object convert(String paramValue) {
                 return Long.valueOf(paramValue);
             }
         });
         stringConverters.put(Float.class, new Converter() {
             public Object convert(String paramValue) {
                 return Float.valueOf(paramValue);
             }
         });
         stringConverters.put(Character.class, new Converter() {
             public Object convert(String paramValue) {
                 return Character.valueOf(paramValue.charAt(0));
             }
         });
         stringConverters.put(Double.class, new Converter() {
             public Object convert(String paramValue) {
                 return Double.valueOf(paramValue);
             }
         });

     }

... inside BasicComponentParameter.  Its not so generified, but we  
don't need the provides() method as the key to the map, is the clue  
to whether it can do it or not.  Its a shame that each of those inner  
classes is 800 bytes or so.

I think for now, a fixed list of conversions is fine - going up to  
the set that XStream caters for.

Later on we could have DPC.addTypeConverter(..) at an instance level.

Thoughts?

- Paul

On Nov 10, 2007, at 3:25 PM, Jörg Schaible wrote:

> Paul Hammant wrote:
>
> [snip]
>
>> I'd love to stop using the XSteam converters, and just use the miriad
>> of built in converters in the JDK ...
>>
>>      Currency.getInstance(paramValue)
>>      Float.valueOf(paramValue)
>
> Hmmm. Remember XStream's ToStringConverter that was contributed by  
> you?
> Since Pico is now Java 5 it should be quite easy to provide some  
> generic
> parameter factories (Pico only needs 'em oneway only). Some pseudo- 
> code:
>
> interface ParameterFactory<T> {
>     bool provides(Class<U> type);
>     T fromString(String s);
> }
>
> abstract class AbstractParameterFactory<T> implements PF<T> {
>     bool provides(Class<U> type) {
>         return T.class == U.class;
>     }
> }
>
> class StringConstructorParameterFactory<T> extends APF<T> {
>     T fromString(String s) {
>         return new T(s);
>     }
> }
>
> class NewInstanceParameterFactory<T> extends APF<T> {
>     T fromString(String s) {
>         return T.newInstance(s);
>     }
> }
>
> class ValueOfParameterFactory<T> extends APF<T> {
>     T fromString(String s) {
>         return T.valueOf(s);
>     }
> }
>
> class EnumParameterFactory<T> extends APF<T> {
>     T fromString(String s) {
>         return Enum.valueOf(T.class, s));
>     }
> }
>
> ...
>
>> This would allow a massive simplification of the implementation, and
>> meet the my need, Konstantin's original need, and the needs in the
>> lastest thread.
>
> The only missing part is now to have a factory for the
> ParameterFactories ;-)
> However, all that is necessary is a (enhanceable ?) list of class  
> types for
> each ParameterFactory.
>
> WDYAT ?
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email