<span id="mailbox-conversation"><div>| <span style="color: rgb(73, 79, 80); font-family: 'Helvetica Neue'; line-height: normal;">I find jc's comment odd:</span>
</div>
<p class="p2" style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: 'Helvetica Neue'; min-height: 17px; color: rgb(73, 79, 80);"><i></i>|</p>
<div><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></div>
<div><i><br></i></div>
<div>I’ll try to explain it better.</div>
<div><br></div>
<div>A lot of stuff has happened in the rails stack before you use an ActiveRecord model to update the database. Immutability is more obviously an advantage in other parts of the stack. For example, I think we typically expect Controllers to be immutable. If we call ‘request’ or ‘render’ multiple times we expect them to always behave in the same way and return the same result. I think you could make the same argument for params - it doesn’t feel right to me that you can change the params inside your controller.</div>
<div><br></div>
<div>In your question you only asked about ActiveRecord, or some ActiveRecord like ORM. You don’t have to write code like this. You could, for example, have created a ChangeSet object that stores a list of modifications that need to be made to the database. For me, it would make sense that this kind of object would be immutable. And this kind of object isn’t providing an abstraction for your database - for your global mutable state. Instead it’s designing your software from the outset to work with data that you don’t have a need to modify.</div>
<div><br></div>
<div>But you’re using Rails, and presumably using ActiveRecord, so you are using a framework that expects mutable objects. The API for ActiveRecord presupposes you will create and then mutate the objects. So if you ask ‘what are the advantages of immutable objects here?’ the answer is ’stop’. (The answer is gramatically incorrect but it’s still the right answer.)</div>
<div><br></div>
<div>This leaves you with a mutable Request object that you’ll use for other things, and I think that this permits a whole class of bugs that shouldn’t even be possible. I gave the example of passing it to a logging function and you rightly said that this shouldn’t change anything. So imagine part of your controller looks something like this:</div>
<div><br></div>
<div>def create</div>
<div>  @request = Request.find(params[:id])</div>
<div>  @request.update_attributes(:state => :denied)</div>
<div>  log(@request)</div>
<div>  # default render</div>
<div>end</div>
<div><br></div>
<div>And then your log method says something like:</div>
<div><br></div>
<div>def log(request)</div>
<div>  if request.state = :allowed # oops - typo</div>
<div>    # log something</div>
<div>  end</div>
<div>end</div>
<div><br></div>
<div>By the time you get to the view your request object will have changed to show the incorrect answer.</div>
<div><br></div>
<div>In simple code this isn’t much of a problem because simple code is, by definition, simple. But as code gets more complex then the number of potential errors like this increases, and they become harder to track down.</div>
<div><br></div>
<div>One of the big benefits of immutability is something called referential transparency. It’s a bit of a fancy sounding term, but it just means ‘when I call the same function with the same arguments it should always do the same thing’. This only really works if your code doesn’t have side effects - such as updating some kind of shared state. Once you allow mutable objects then you lose referential transparency and your code is harder to reason about. To understand what it does you not only need to understand that function, but also understand any other function that might have accidentally caused some side effect that affects the outcome.</div>
<div><br></div>
<div>Immutability isn’t always the correct answer. Sometimes you want state or other side effects and this introduces complexity in languages that only allow immutable data. You typically work around this by always passing ‘state’ into every function, and always returning a modified state. (In strongly typed languages this leads to monads, which are yet more complexity.) This is a different way of thinking about how you solve problems and, like any programming technique, it isn’t perfect for all situations.</div>
<div><br></div>
<div>Immutability is, in general, a good idea. It makes code easier to reason about. But like a lot of good ideas it doesn’t really work in Rails, especially in relation to ActiveRecord-like ORMs. I don’t think you are really asking ‘what are the advantages for immutable objects in web apps?’. You seem to be asking ‘what are the advantages for immutable objects when thinking about persistence in a rails-like framework?’ and the answer is ‘that’s not really appropriate’. This isn’t a bad answer - if your application is simple and you’re not having problems with accidental side-effects, or having problems reasoning about the code, then Rails with it’s mutable objects is probably a good solution. But IMO it becomes less good as your code becomes more complex, and making immutability the default can help keep your code manageable as it grows.</div>
<div><br></div>
<div>I hope that makes it a bit clearer.</div></span><div class="mailbox_signature"><br></div>
<br><br><div class="gmail_quote"><p>On Thu, Sep 10, 2015 at 8:49 AM, Jonathon Horsman <span dir="ltr"><<a href="mailto:jonathon@arctickiwi.com" target="_blank">jonathon@arctickiwi.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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">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">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">Twitter</a> <a href="https://github.com/gerhard">Github</a> </font><a href="http://gerhard.lazu.co.uk/" style="font-family:arial,helvetica,sans-serif">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">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">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">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br><br></blockquote>
</div>
<br></div>
</div>
</div></div></blockquote></div><br>