Re: [Converter] DTOs with methods?

Hi David L, I've implemented an initial version here: https://svn.apache.org/viewvc?view=revision=1765430 I had to rename the methods a little bit. The to() has the actual implementation type, just as before. The new method added is target() which is where you can specify how to view the target

Re: [Converter] DTOs with methods?

HI David B., Yup, something like that would do just fine!! Thanks a lot. Cheers, =David > On Oct 18, 2016, at 7:43 PM, David Bosschaert > wrote: > > Hi David L, > > The as() method (at least in its current incantation) say something about > how to treat the

Re: [Converter] DTOs with methods?

Hi David L, The as() method (at least in its current incantation) say something about how to treat the source object - the thing you are converting from. So in your example myDtoWithMethods = converter.convert(map).as(PlainDTO.class).to(DtoWithMethods.class) it would try to treat the source

Re: [Converter] DTOs with methods?

Hi David B., Thanks for this suggestion. That would indeed work nicely. As you say, it requires an extra class, but at least there is very little duplication, at least converting TO something. Converting TO: > Map m = converter.convert(myDtoWithMethods).as(PlainDTO.class).to(Map.class)

Re: [Converter] DTOs with methods?

Hi David L, Recently I added the 'as()' method to the converter, which is really meant to disambiguate source objects. Let's say you have an object that is both a JavaBean as well as implementing an interface. The Converter spec will specify some 'priority' rules for this, but they may not always

Re: [Converter] DTOs with methods?

Hi David B., Thanks. I think you’re right, the spec is quite clear. If I wanted to treat any class like a DTO (ignore the methods and use only the public fields — just like before the recent changes made to the code base), can you think of any way? Perhaps having “strict” mode to follow the

Re: [Converter] DTOs with methods?

Hi all, The OSGi spec for DTOs is pretty clear. Section 57.2 of the R6 Core spec states: "Data Transfer Objects are public classes with no methods, other than the compiler supplied default constructor" Therefore I would be reluctant to use a different definition for the Converter. OTOH I think

Re: [Converter] DTOs with methods?

Hi David L, I imagine the “extra step” and “redirection” are the need to create both the SomeDTO and the SomeImpl? Thinking about this a bit more I’m reminded that sometimes I end up thinking that putting that first “this” parameter back into every method that C++ took out might be a good

Re: [Converter] DTOs with methods?

Hi David J., That is an interesting perspective. Also based on the ideas proposed by Peter, and after a bit of experimentation, these are my thoughts: * Java object encapsulation “works", but only if we assume that there is no such thing as reflection. Since an object can be

Re: [Converter] DTOs with methods?

A while ago Peter said something about DTOs violating data hiding or encapsulation and I decided that if you think of the DTO as a primitive data type they don’t. Following this line of thinking (which I have not been able to try out in practice, just as thought experiments) you’d have