Re: [morph-developer] InstantiatingReflector

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

I agree, the addition of the "Object parameters" parameter to 
InstantiatingReflector.newInstance is worrisome.  The idea behind a 
Reflector in general is that it tells you how to work with some new type 
of object that has properties which are not known until runtime.  For 
example, Maps, DynaBeans, ResultSets, etc.  If you have some sort of 
domain object there should be no need to write a reflector, because 
Morph's built-in ObjectReflector can use Java's built-in reflection 
capabilities to determine the properties of the object.  If you just 
want to be able to convert stuff, it should be sufficient to write a 
single Transformer that implements both Converter and Copier interfaces 
and doesn't mess with InstantiatingReflectors at all.

That said, I think the InstantiatingReflector.newInstance method is 
something that should be present in the API and not deprecated.  We can 
and should specify in the comments what this method should and should 
not be used for.  However, it is possible that some types of dynamic 
objects would require extra information before they are created.  For 
example, the BasicDynaBean has no default constructor and requires a 
DynaClass to be constructed.  Its properties are not known until 
runtime, but the DynaClass provides a contract describing the object's 
properties, etc.

So in summary, I'm saying I think we have a documentation issue not an 
API issue.  However, I don't fully understand what API changes you are 
proposing, so could you post some pseudo code for us to look at?

Thanks,

Matt S

Matt Benson wrote:
> I am reawakening this thread.  I touched on this
> subject during the original discussion, but at the
> time I couldn't quite articulate what was bothering me
> about the whole business.  Last Friday it burst upon
> me, and I have continued to kick it around over the
> weekend but have not been able to refute my own logic:
>
> Basically with InstantiatingReflector taking a source
> parameter, it IS a converter.  What is the difference
> between:
>
> InstantiatingReflector.newInstance(Class, Object)
> -and-
> DecoratedConverter.convert(Class, Object)
> ?
>
> >From my POV, nothing.  Different semantics for what,
> using the method parameters as an indicator, is one
> concept.  The role of the InstantiatingReflector in
> the Morph library is to adapt a copier to the
> converter interface, using the following algorithm:
>
> 1. Create a new instance I
> 2. Invoke copy() using I as the destination object.
>
> This sequence of operations amounts to a "derived
> conversion":  one which relies on a parent conversion
> to supply the target object, then modifies the
> resulting object.  This modification will always
> consist of making changes on a target object based on
> the source object (otherwise the parent converter
> alone would suffice), and thus infallibly corresponds
> in intent with Copier.copy().  This proves that a
> DerivedConverter is precisely a Copier that implements
> Converter by first delegating to a parent Converter,
> then copies the source to the resulting destination
> object.  The parent converter can be overridden, but
> would default to an, e.g., NewInstanceConverter which
> simply creates a new instance of the destinationClass.
>
> In adopting the DerivedConverter concept,
> InstantiatingReflector would, in my opinion, no longer
> be needed, and would hopefully be deprecated and then
> removed as soon as the current players on the mailing
> list(s) are all up to speed.  Because the interfaces
> are so similar, I would expect the refactoring of a
> custom InstantiatingReflector implementation to a
> custom Converter implementation to be trivial.
>
> I invite discussion, but I really think I have
> something here.
>
> Impatiently awaiting comment,
> Matt B
>
>
>  
> ____________________________________________________________________________________
> We won't tell. Get more on shows you hate to love 
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265 
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>