Re: [morph-developer] InstantiatingReflector

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

Thinking more on this, it seems more correct that a
basic implementation of newInstance(Object parameters)
would look for constructors matching the parameters,
and failing to find any would fall back to the
no-parameter version.  This would probably be MORE
compatible with any existing InstantiatingReflector
implementation as well.

-Matt

P.S. Sorry about the bleeding ocular cavity problem. 
;)


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

> That sounds like a good approach Matt B.  That way,
> if someone has a 
> reflector that extends from BaseReflector, it will
> still work with the 
> new version of Morph despite the interface change (I
> think).  Actually 
> to be really technical, BaseReflector.newInstance is
> final, so it's safe 
> to just change that to match the new signature. 
> Then 
> newInstanceImpl(Class) can call
> newInstanceImpl(Class, Object)
> 
> BTW, I'm still trying to catch up to all the changes
> you made to Morph 
> this week.  I haven't been able to finish, but so
> far they look good.  I 
> do see you love the ? : operator ;)  I'm fine with
> using it extensively, 
> but I did run into 1 or 2 places that made my eyes
> bleed because I 
> couldn't figure out what was going on.  More to come
> later...
> 
> Matt
> 
> Matt Benson wrote:
> > 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 
> >
> >
>
-------------------------------------------------------------------------
> > 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!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com