<div dir="ltr">A lot of these solutions to updating an object seem to suggest "don't change the existing object but create a new object such as a 'response' or 'consent'".<div><br></div><div>To me that is adding more complexity. If I want to display a list of these request objects and their current state I have to also query for their response object(s) and find the latest one for each.</div><div><br></div><div><div class="gmail_extra">And it doesn't address the situation when a user updates their email address, presumably that will require an update to an existing user object?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I find jc's comment odd:</div><div class="gmail_extra"><span style="font-size:12.8px"><i><br></i></span></div><div class="gmail_extra"><span style="font-size:12.8px"><i>So now that the problem is phrased in terms of wanting to manipulate shared global state then mutability seems like the correct option.</i></span></div><div class="gmail_extra"><br></div><div class="gmail_extra">given that having a data store as a shared global state the situation in the vast majority of apps? Surely shoe-horning immutable objects onto a mutable data store would always be the wrong solution?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Clearly I'm missing something - I appreciate your input.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jonno</div><div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2015 at 19:21, Gerhard Lazu <span dir="ltr"><<a href="mailto:gerhard@lazu.co.uk" target="_blank">gerhard@lazu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Should a Request know or even care about its denial? Which parts of your app need to know about request denials?<div><br></div><div>These questions are meant to open up the path to your answer. Simple Design by Corey Haines will help.</div><div><br></div><div>I can only reinforce Roland's point: keep it simple.</div><div><br></div><div>Gerhard<div><div class="h5"><span></span><br><div><br>On Wednesday, 9 September 2015, Jonathon Horsman <<a href="mailto:jonathon@arctickiwi.com" target="_blank">jonathon@arctickiwi.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hey smart people<div><br></div><div>Can you shed some light on why an immutable object is an advantage for a web-based Ruby app?</div><div><br></div><div>For example this app I'm working on has these Request things and a user has the ability to deny a Request.</div><div><br></div><div>So the user would click a button which performs a post to the Request controller's deny action.</div><div>If I were using Rails or some non-immutable based system I would fetch the object from the database, set it's status to denied, and save it.</div><div><br></div><div>However since this Request is an immutable object, I have to either:</div><div><br></div><div>1. Write an update_status method which sets that value in the database, which becomes tedious when there's lots of possible attribute update combinations</div><div>or</div><div>2. Read the object from the database, copy all the values to a new object with the denied status, and stick that back into the database. Seems like pointless overhead and could be dangerous if later that object gets another attribute which I forget to copy.</div><div><br></div><div>My knowledge of immutable objects originates with Java Strings which I understand makes sense for performance and memory management reasons.</div><div>I don't think this applies here though?</div><div><br></div><div>Thanks!</div><div><br></div><div>Jonno</div></div>
</blockquote></div></div></div></div><span class=""><font color="#888888"><br><br>-- <br><div dir="ltr"><br><hr style="font-family:arial,helvetica,sans-serif"><font color="#3333ff"><font face="arial, helvetica, sans-serif"><a href="http://twitter.com/#!/gerhardlazu" target="_blank">Twitter</a> <a href="https://github.com/gerhard" target="_blank">Github</a> </font><a href="http://gerhard.lazu.co.uk/" style="font-family:arial,helvetica,sans-serif" target="_blank">Blog</a></font></div><br>
</font></span><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div></div></div>