Re: [morph-developer] InstantiatingReflector

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

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