On 13 apr. 2014, at 12:45, Gunnar Morling <notifications@github.com> wrote:

> In processor/src/main/java/org/mapstruct/ap/conversion/SimpleConversion.java:
> 
> >       */
> > -    protected abstract String getToConversionString(String sourceReference, ConversionContext conversionContext);
> > +    protected abstract String[] getToExpressions( ConversionContext conversionContext );
> I think I understand what you mean :) I feel though (and IIUC that's also @agudian's concern) that the conversions themselves got much more complicated with this change.
> 
> 
But in what sense? Inside the conversions the code has become more transparent. Take for instance `BigDecimalToPrimitiveConversion`: This is something you can read immediately:  `return new String[]{ "BigDecimal.valueOf( ", " )" };` (I would think :) )

> Indeed this change seems to remove quite a few redundancies, but I find it more and more hard to get - from looking at the templates - what the generated output will be.
> 
> Couldn't a conversion have:
> 
> a) a source reference as before (for the case it has no nested other conversion or method reference) OR
> b) a nested other conversion or method reference
> 
> 
I doubt that choices will make it more easy. I now have a `SimpleAssignment` which is basically a wrapper around `sourceReference` which can be anything: a reference to a source method, but also a fixed (constant) String as we discuss later on.
> I think this would still allow to set the begin and end part directly within the template (making it a bit nicer to grasp), and between the two either the reference from a) or the other templated object from b) is included.
> 
> 
But I still fail to get how you would create a String out of the methodReference (template). Because this is what you have to substitute the `sourceReference` with. 

Perhaps you can take #200 and have your suggestions in and see were you hit rock-bottom :).
> This leaves a problem where the nested conversion/method declares exceptions, though. This could possibly be solved by "pulling out" the exeptions and generating them only for the outermost conversion (i.e. a conversion would need to know whether it's nested or not, so it doesn't render the try/catch itself in case it is nested).
> 
> 
That’s solved by creating Decorators (as Andreas suggested). Sorry for the confusion with your generated Decorators (perhaps i should rename to wrapper), but the intention is that each wrapper adds a piece of functionality to the Assignment, such as a try-catch or a null-check.
> Al that said, I really like that we get rid of the repeated code between the different mapping methods :)
> 
> 
Thanks ;) So how do we continue from here on.  I split this one into two pull requests as you proposed: #157 and issue #200. I’ll have a look at your other comments and I’ll fix those. But I still think that separating the TypeConversions (into pre - expression -post) is the way forward to get maximum reuse.
> —
> Reply to this email directly or view it on GitHub.
>