commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [Morphos] Java data morphing package - second stab
Date Thu, 06 Jun 2002 22:19:41 GMT
From: "Tim Moore" <>

> From: Nicola Ken Barozzi []
> > IMO you are right, immutable objects make the morph(input,
> > output) method a bit ridiculous.
> >
> > I think you've convinced me, what do others think?
> I agree...I see no way around having two different interfaces, though:
> one that converts the input into a new immutable object, and another
> that modifies an existing mutable object.

I guess you're right...

> Now that being said, the commons already has an interface for the
> former: org.apache.commons.beanutils.Converter.  Maybe all that's needed
> is for Morphos to play well with and possibly subsume the BeanUtils
> ConvertUtils/Converter stuff.

Yes, Morphos aims at making many different projects interact together to
convert objects, and I think I will use that package to configure morphers.

> I imagine that a Morpher would be commonly defined as a series of
> sub-morphs and conversions of its properties.

In fact MorpherPipeline extends Morpher.

>  Ideally it would be nice
> to be able to ultimately define "DynaMorphers" declaratively as a
> sequence of primative morphs and conversions and have the framework
> handle the work. ;-)

Now you see where I'm heading :-)
Good, it means that the API starts to make sense.

In fact the MorpherManager coud become a DynaMorpherManager, that gives you
a morpher by automatically putting the right morphers in place to get you
from the input to the output you want.

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message