Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt S. <Mat...@wh...>]

I think for almost all transformers where source and destination classes 
are not static we should make the mutators public.  So: 
ChainedConverter, ConverterDecorator, CopierDecorator, CumulativeCopier, 
AssemblerCopier, MultipleDestinationConverter.  I don't think they need 
to be public on SimpleDelegatingTransformer.

More responses below...

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> Short answer: I think it's better to leave it
>> protected in 
>> BaseTransformer and just override it to be public in
>> ChainedConverter.
>>     
>
> Fair enough.  In my use case I was thinking originally
> of the ubiquitous pattern of a TextToFoo converter
> that uses a TextConverter to magically get all its
> conversions and basically is a hand-run
> ChainedConverter with two components.
Should we make a base class for this purpose?  After all, entire 
conversion frameworks have been built on Object -> String and String -> 
Object conversions rather than Object -> Object conversions.  
Unfortunately the name "TextConverter" is taken so BaseTextConverter 
would be rather confusing :(

This is a bad name, but I'm thinking something like 
BaseBiDirectionalTextConverter, so if I have some object Foo I want to 
allow to be magically turned into all sorts of things then I extend 
BaseBiDirectionalTextConverter and it automatically takes care of foo -> 
(text) and (text) -> foo.

public abstract BaseBiDirectionalTextConverter extends BaseTransformer {
    private Converter textConverter;
    public abstract String toText();
    public abstract String toObject();

    // implementation details
}

> Take two of
> these and pass to a chainedconverter, so that you have
> the ultimate transformation of 
>
> FooToTextConverter, TextToBarConverter:
> Foo -> (text) -> Bar
>
> Here there are several classes that are both a valid
> destination for FooToText and a valid source for
> TextToBar.  The current ChainedConverter
> implementation will take the first overlap it finds
> and be happy.  But if it happens to choose Character
> or char data will be lost if the intermediate text
> representation is > 1 character long.
The algorithm will go with the first match, so StringBuffer should be 
chosen right?  I assume you are using this just for illustration 
purposes to point out why ChainedConverter should have mutable source 
and destination classes (a point I agree with).

> I realized that
> for my immediate purposes I should simply override the
> setters in the TextToFoo/FooToText type classes.  For
> something that might be usable out of the box, it
> seems like it might be appropriate to open access to
> these methods on ConverterDecorator and
> CopierDecorator for a reasonable way to wrap the
> bundled converters/copiers.  WDYT?
>   
I absolutely agree the mutators should be public on both decorators.

I hope there isn't ever a need to wrap a transformer bundled with Morph 
with one of the decorators though.  After all, the transformers we have 
out there already implement all the interfaces the decorators do and the 
whole point of a decorator is that it implements an interface the 
decorated object does not.
> -Matt

Oh I don't have to write my name this time! ;)

PS - it occurred to me that we (I) need to add transformers that support 
Streams.  Often the first time someone hits an InputStream or 
OutputStream, they could be safely working with Strings or byte[] arrays 
or something instead and get the job done.  I know the first time I had 
to use an InputStream I nearly went insane because all I needed was a 
freakin String.  For that matter, I guess all of the java.io. stuff and 
Spring resource stuff could use transformers...

PPS - have you seen this thread

http://www.nabble.com/-convert--Project-restart---tf2015876.html#a5603065

Now I know why Henri is interested in Morph.