<div dir="ltr"><div dir="auto"><div><br></div><div>In every example I've seen immutability has certainly required more effort, but I don't think this always correlates with more complexity. However, I find people usually have their own idea of what simplicity looks like.</div><div><br></div><div>Given that we model a request / approval system using a single table of requests with an `approved_at` field, what happens if a approval is submitted twice, at different times or perhaps concurrently? </div><div><br></div><div>The obvious solution is to throw in an `if` statement checking whether approval has already happened. Perhaps we would allow `approved_at` to be overwritten multiple times (can of worms there). Maybe we could use a database transaction to prevent it, then dependent on which isolation level we choose this could block or raise an exception.</div><div><br></div><div>In future would it be desirable to know about multiple approvals? What about if requirements change and multiple users must approve a request?</div><div><br></div><div>This is all hypothetical of course, but we never know what future requirements will be. I would have to insist that none of the solutions I suggested above sound simple at all. On the other hand choosing an immutable, append only approach seems like more effort but I would feel much better placed to answer the questions about edge cases and future requirements.</div><div><br></div><div>Bestie.<br><br><div><br></div></div><div>On 10 Sep 2015, at 08:49, Jonathon Horsman <<a href="mailto:jonathon@arctickiwi.com" target="_blank">jonathon@arctickiwi.com</a>> wrote:<br><br></div><blockquote type="cite"><div><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><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><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" target="_blank">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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Chat mailing list</span><br><span><a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a></span><br><span>Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a></span><br><span>Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a></span><br><span>List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></span><br></div></blockquote></div></div>