Re: [morph-developer] InstantiatingReflector

[Matt B. <gud...@ya...>]

Matt:  I was curious what your take on this would be. 
I was actually about to answer Ben myself before I saw
that you just had.  Anyway, even taking the approach
of modifying the existing interface, do(n't) you think
newInstance(Class clazz, Object parameters) should be
a new method entirely, and that BaseReflector can just
pass null parameters from the old method to the new
method?

-Matt B

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Hi Ben - at first I was quite uncomfortable with the
> idea of adding a 
> new parameter to the newInstance method, if only
> because it takes a very 
> simple method and makes it more complex..  However,
> after thinking about 
> it I see that we don't really have a choice.  If you
> have an object in 
> some external API over which you have no control
> like this
> 
> public class Foo {
>    public Foo(int requiredConstructorParam) { }
>    private Foo() { }
> }
> 
> Then there is no way to create the object without
> passing in the 
> requiredConstructorParam (e.g., java.lang.Integer
> works like this).  So, 
> when the object is created you really do need more
> information than just 
> the class of the object to be created.  One minor
> thing is that 
> reflectors don't necessarily have anything to do
> with transformations 
> (though that is the way they will generally be
> used).  So I would change 
> the name of the new parameter you introduced to be
> "parameters", which 
> indicates the object is one or more parameters used
> in the object 
> creation.  In BaseTransformer, we would pass in the
> source object.  In 
> some other use case, perhaps parameters would be a
> Map with name/value 
> keys for the different fields to be initialized in
> the new instance.  
> What was required of the "parameters" object would
> be dictated by the 
> particular Reflector implementation.
> 
> public Object newInstance(Class clazz, Object
> parameters) throws
> ReflectionException;
> 
> I'm inclined to just add the parameter to the base
> interface, despite 
> the potential for some compatibility issues. 
> Logically when you create 
> an instance of an object there's the potential for
> you to need to know 
> more information than just the class, and I don't
> think it makes sense 
> to support 2 different interfaces when 1 will
> suffice.
> 
> Matt
> 
> Ben Alex wrote:
> > Hi
> >
> > We have a requirement to instantiate objects using
> complex constructors
> > (not simply no-argument constructors). Essentially
> we will use parameter
> > name discovery to retrieve the request parameter
> names from the
> > constructor, then source the properties from the
> input object. We do
> > this with Dozer quite successfully.
> >
> > InstantiatingReflector appears the appropriate
> Morph interface:
> >
> > public Object newInstance(Class clazz) throws
> ReflectionException;
> >
> > This is invoked by the BaseTransformer method:
> >
> > protected Object createNewInstanceImpl(Class
> destinationClass,
> >                              Object source) throws
> Exception;
> >
> > I would like to request a change so that
> InstantiatingReflector is
> > provided the source object, which we need in order
> to perform the
> > desired destination object construction. ie:
> >
> > public Object newInstance(Class clazz, Object
> source) throws
> > ReflectionException;
> >
> > I don't see this as a major problem, given that
> existing
> > InstantiatingReflector implementations can simply
> ignore the additional
> > parameter if they don't wish to use it.
> >
> > Alternately, if backward compatibility were an
> issue, could we have a
> > new interface (InstantiatingSourceReflector?)
> which provided the
> > interface, and have this new implementation extend
> > InstantiatingReflector. Then BaseTransformer would
> detect the type of
> > instantiating reflector injected and invoke
> accordingly.
> >
> > I realise we could simply override the
> BaseTransformer method, but then
> > we force concrete inheritance to be used when a
> strategy pattern already
> > exists and makes more sense. We just need the
> strategy to present the
> > additional parameter.
> >
> > I'm happy to make this change and provide a patch,
> but I wanted to check
> > which approach (or some other) that people
> preferred.
> >
> > Thanks
> > Ben
> >
> >
>
-------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of
> IT
> > Join SourceForge.net's Techsay panel and you'll
> get the chance to share your
> > opinions on IT & business topics through brief
> surveys - and earn cash
> >
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com