commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <>
Subject RE: [Morphos] Java data morphing package - second stab
Date Thu, 06 Jun 2002 21:34:15 GMT
See comments below...

Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

> -----Original Message-----
> From: Nicola Ken Barozzi [] 
> Sent: Thursday, June 06, 2002 4:27 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Morphos] Java data morphing package - second stab
> From: "Stephen Colebourne" <>
> > The problem with the two object input approach is that it 
> > precludes a simple type convertor being written using
> > this architecture. A type convertor typically takes in an
> > immutable object and returns an imutable object 
> > (String/Integer etc.)
> Hmmm...
> Integer input = new Integer(1);
> String output = null;
> [...]
> mymorpher.morph(input , output);
> If the morpher does
>   output=input.toString();
> wouldn't it work?

No, because remember that in Java, Object references are passed by
value.  In other words, that would only change the value of "output" in
the scope of the morph method--not in the calling code.

> 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.

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.

I imagine that a Morpher would be commonly defined as a series of
sub-morphs and conversions of its properties.  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. ;-)

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

View raw message