Re: [Converter] DTOs with methods?

2016-10-18 Thread David Bosschaert
Hi David L, I've implemented an initial version here: https://svn.apache.org/viewvc?view=revision&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

Re: [Converter] DTOs with methods?

2016-10-18 Thread David Leangen
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 source object - the thing you

Re: [Converter] DTOs with methods?

2016-10-18 Thread David Bosschaert
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 map

Re: [Converter] DTOs with methods?

2016-10-18 Thread David Leangen
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) When

Re: [Converter] DTOs with methods?

2016-10-18 Thread David Bosschaert
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?

2016-10-18 Thread David Leangen
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 s

Re: [Converter] DTOs with methods?

2016-10-18 Thread David Bosschaert
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?

2016-10-15 Thread David Jencks
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 ide

Re: [Converter] DTOs with methods?

2016-10-15 Thread David Leangen
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 introspected

Re: [Converter] DTOs with methods?

2016-10-15 Thread David Jencks
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 public

[Converter] DTOs with methods?

2016-10-15 Thread David Leangen
Hi! I only noticed now that according to the RFC, DTOs cannot contain methods. I can understand why this is so, and I do not object. However, I have found a very practical design pattern whereby I use classes that act both as DTOs and domain value objects. In effect, this means that they are

[Converter] DTOs with methods?

2016-10-14 Thread David Leangen
Hi! I only noticed now that according to the RFC, DTOs cannot contain methods. I can understand why this is so, and I do not object. However, I have found a very practical design pattern whereby I use classes that act both as DTOs and domain value objects. In effect, this means that they are