So copy could work for immutability but it limits my ability to help the client (which is normally me and I am definitely stupid enough to not think about how I designed the system) but it doesn't help with how to add mutability of data objects transferred between services. I do think I may be trying to do too much with DTO's but I am still trying to wrap my head around where they should be used. Do I just use them as pojo's that come in and out of services and then immediately convert them to domain specific objects or do I let them stick around and try and make use of them.
On Thu, Aug 18, 2016 at 8:26 AM, David Leangen <[email protected]> wrote: > > David D., > > No! You just need to copy the DTO. Let the client do whatever it wants > with the DTO; it won’t mess up the system. If the client is “stupid” enough > to change the value of the DTO, then that’s the client’s problem. > > There is no more worry about immutability / value object. There are only > copies of objects. > > BTW, that is why I suggested that we add a copy() method. > > It does take a change of mindset. I also came from the School of Immutable > Objects. But copying objects works, too. > > > Cheers, > =David > > > > > On Aug 18, 2016, at 9:16 PM, David Daniel <[email protected]> > wrote: > > > > So for the article above what I am struggling with is how to do > > immutability/mutability with the DTO spec. With java beans there is a > get > > and set method for each attribute. If DTO's had this the way I would do > it > > is as follows. I would have an attribute for mutability that is either > > true or false. If false I would put an aspect around the get function > that > > returns a clone of the attribute value. I would put an aspect around the > > set function that throws an exception. For mutable DTO's my converter > > would delegate deserialization to a CRDT service that would put aspects > > around set that watches for changes and aspects around get/set that > throws > > an exception if called when the DTO is in a conflicted state. The CRDT > > service would then return the DTO to the converter. On update it > modifies > > the CRDT structure as above. In the converter if the DTO is watched then > > when serializing it delegate serialization to the CRDT service. I am not > > sure how to model immutability with the current DTO standard because > there > > are no get or set functions that I can put aspects around. > > > > On Thu, Aug 18, 2016 at 6:40 AM, David Daniel < > [email protected]> > > wrote: > > > >> For me helps by having the schema that allows for something some other > >> service uses to do the automatic merging using the tools available in > >> dosgi, but I understand that nothing can be really automatic because it > can > >> require merges and there is garbage collection that will need to happen > on > >> the objects during reconciliation. If the DTO's are just public fields > >> they do not offer anything over using a pojo. Where they start to be > >> useful to me is by defining in a standard way how the data can be turned > >> into an object. Examples would be a way to define a key so that indexes > >> and equality can be determined, or defining relationships between sub > >> objects so when doing a deep clone the user can decide how many links to > >> traverse. Scoping rules could also be defined so the converter has > >> information that could be used in determining which type of object to > >> serialize to in different situations. The standard can choose not to > >> define these things and let the application decide in order to be more > >> flexible or it can try to define some of these things in order to make > >> services or tools around DTO's more standardized. I think I am trying > to > >> follow what schema elements will be in DTO's and make sure that I take > >> advantage of them rather than writing my own. As of right now that I am > >> just using them as pojo's though so I don't have any feelings or advice > on > >> the way to go and what types of schema things I would be able to take > >> advantage of. > >> > >> On Thu, Aug 18, 2016 at 4:23 AM, David Bosschaert < > >> [email protected]> wrote: > >> > >>> Hi Davids, > >>> > >>> What is it exactly from that article that you think would make sense in > >>> the > >>> context of OSGi? The automatic merging of concurrent data updates? > >>> > >>> Thanks, > >>> > >>> David > >>> > >>> On 18 August 2016 at 07:50, David Leangen <[email protected]> wrote: > >>> > >>>> > >>>> That is interesting, indeed! I only quickly skimmed through the > article, > >>>> but it does indeed appear to be a potentially interesting property for > >>>> dosgi. > >>>> > >>>> If I believe what the authors write in the abstract, it provides a > >>>> relatively simple and deterministic method that could be implemented > in > >>>> code. > >>>> > >>>> Cheers, > >>>> =David > >>>> > >>>> > >>>>> On Aug 17, 2016, at 10:21 PM, David Daniel < > >>> [email protected]> > >>>> wrote: > >>>>> > >>>>> read an interesting article this morning > >>> http://arxiv.org/abs/1608.03960 > >>>>> Something like this would be an interesting property to have for > dosgi > >>>>> which is one of the use cases for DTO's > >>>>> > >>>>> On Wed, Aug 17, 2016 at 6:47 AM, David Leangen (JIRA) < > >>> [email protected]> > >>>>> wrote: > >>>>> > >>>>>> > >>>>>> [ https://issues.apache.org/jira/browse/FELIX-5325?page= > >>>>>> com.atlassian.jira.plugin.system.issuetabpanels:comment- > >>>>>> tabpanel&focusedCommentId=15424288#comment-15424288 ] > >>>>>> > >>>>>> David Leangen commented on FELIX-5325: > >>>>>> -------------------------------------- > >>>>>> > >>>>>> Awesome. Thank you! :-) > >>>>>> > >>>>>>> Patch for embedded DTO (in DTO) > >>>>>>> ------------------------------- > >>>>>>> > >>>>>>> Key: FELIX-5325 > >>>>>>> URL: https://issues.apache.org/jira > >>> /browse/FELIX-5325 > >>>>>>> Project: Felix > >>>>>>> Issue Type: Improvement > >>>>>>> Components: Converter > >>>>>>> Reporter: David Leangen > >>>>>>> Assignee: David Bosschaert > >>>>>>> Priority: Minor > >>>>>>> Attachments: patch.diff > >>>>>>> > >>>>>>> > >>>>>>> This patch adds support for converting a DTO that contains an > >>> embedded > >>>>>> DTO. It uses recursive calls to Converter.convert() to accomplish > >>> this. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> This message was sent by Atlassian JIRA > >>>>>> (v6.3.4#6332) > >>>>>> > >>>> > >>>> > >>> > >> > >> > >
