<div dir="ltr">It's probably worth throwing up a reference to functional purity:<div><br></div><div><a href="https://en.wikipedia.org/wiki/Pure_function">https://en.wikipedia.org/wiki/Pure_function</a></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>