<div dir="ltr">Hey thanks for the responses.<div><br></div><div>To summarise the main reason appears to be to avoid unexpected changes being made on an object as it is passed around.</div><div><br></div><div>I'm struggling a bit to envisage when this might occur in the relatively simple sorts of apps I'm working on.</div><div><br></div><div>In your experience what sorts of instances has this happened? Logging was mentioned which to me seems extremely unlikely that a logger would mutate an object.</div><div>If it does surely that's a major bug in the logger or a failure of the tests to pick that up?</div><div><br></div><div>In the simple case of say a user in the system updating their email address. They'd have a form which would make a put request to /users/1234</div><div>The process to handle that update in an immutable system would be either:</div><div><br></div><div>Update email address of user with ID 1234</div><div>Update first name of user with ID 1234<br></div><div>Update last name of user with ID 1234<br></div><div>etc...</div><div><br></div><div>OR:</div><div><br></div><div>Read existing user 1234 from database</div><div>Merge new (changed) attributes and unchanged attributes the user doesn't have permission to change, e.g. creation date.</div><div>Create a new user object with the merged attributes</div><div>Persist new object (with same ID) to database</div><div>Pass back new object to caller to be rendered</div><div><br></div><div>Also in this example the mutability would be useful - the caller wants to have the modified object since that's the up-to-date representation.</div><div><br></div><div>Roland your suggestion to create another object would fit in certain cases where you're maintaining a sort of event log of activity, but there are many (most) instances where you need to update a value in a data store rather than provide a sort of versioning. Sorry if I've misunderstood your suggestion.</div><div><br></div><div>Thanks again for your responses.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2015 at 11:43, Roland Swingler <span dir="ltr"><<a href="mailto:roland.swingler@gmail.com" target="_blank">roland.swingler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">> why an immutable object is an advantage<div><br></div></span><div>In general immutability is nice because a lot, lot less can go wrong with immutable objects. A lot of bugs are caused by editing state incorrectly - if you can't change the state of an object then a whole class of bugs vanish by design.</div><div><br></div><div>In terms of your specific problem a way to approach it might be - you have a Request of some form - instead of changing state model what is going on - so create a Response model (almost certainly a better name - I don't know your problem beyond what you've told us) with a state field of denied. To deny a request, create a Response object set to denied.</div><div><br></div><div>This gives you some nice properties - you can start doing things like recording like when the request was denied, who denied it etc. if you like; also if a request is denied by mistake for then you can just create a new Response and you have a history of all the state changes.</div><div><br></div><div>Now, none of this may be practical in your application (for example if lots of other things are already coupled to a mutable state field on your Request). In which case do whatever is simplest.</div><div><br></div><div>Thanks,</div><div>Roland</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Sep 9, 2015 at 11:25 AM, Jonathon Horsman <span dir="ltr"><<a href="mailto:jonathon@arctickiwi.com" target="_blank">jonathon@arctickiwi.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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>
<br></div></div><span class="">_______________________________________________<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></span></blockquote></div><br></div>
<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>