commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <tmo...@blackboard.com>
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 [mailto:nicolaken@apache.org] 
> 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" <scolebourne@eurobell.co.uk>
> 
> > 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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message