<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">There is actually two other benefits, but which I think has been implied by other answers, but I thought I’ll elaborate here. These are benefits of pushing immutability into lower layers, and capturing the mutability at a higher level.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div><b>Easier to detect change</b></div><div><b><br></b></div><div>React(JS) does this pretty heavily. If you have an component with component.state, it’s really hard to detect when someone changes component.state.foo.bar = “new-value”. Instead of this, it’s much easier to ask that your caller replaces the entire value of component.state.</div><div><br></div><div>And since the original map was not altered, it’s possible to basically do something like this</div><div>function setState(newState) {</div><div> oldState = this.state;</div><div> diff fancyDiffAlgorithm(oldState, newState);</div><div> onlyUpdateThePartsOfThePage(diff)</div><div>}</div></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><b>Safer access of the object across threads. </b></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">It’s hard to give a good example, but say you had a global map, “state” with one field “counters”.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">global.state[“counters”] = 0</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The following statement could not run on multiple threads at once:</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">global.state[“counters”] = global.state[“counters”] + 1 </div> <div><br></div>However, if your language exposes a primitive like the compare and swap, and you can immutably “replace" your map, if you write your program as follows<div><br></div><div># Pseudo code, though I believe there is a ruby library that implements this</div><div>compare_and_swap(global.state) { |x| x.merge({“counters”: x[“counters”] + 1})} # Explaining this further in [1]</div><div><br></div><div><div>[1] For people unfamiliar, compare and swap is a concurrency pattern, mostly resembling the following pseudocode</div><div>old = x</div><div>new = f(old)</div><div><br></div><div># next four lines done atomically</div><div>if (x is still == old)</div><div> x = new</div><div>else</div><div> retry until we pass</div><div><br></div><div>The condition is obviously that f(x) must be a pure function, as it runs possibly multiple times until it’s successful. This means it cannot mess up “x”, as other threads may be executing f(x) concurrently.</div><div><br><p class="airmail_on" style="color:#000;">On 9 September 2015 at 8:55:32 pm, Jonathon Horsman (<a href="mailto:jonathon@arctickiwi.com">jonathon@arctickiwi.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<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</span>
<div><span class=""><br></span></div>
<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>
_______________________________________________
<br>Chat mailing list
<br>Chat@lists.lrug.org
<br>Archives: http://lists.lrug.org/pipermail/chat-lrug.org
<br>Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
<br>List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
<br></div></div></span></blockquote> <div id="bloop_sign_1441812440317085952" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><div>-- </div><div>Tejas Dinkar</div><div>Quintype</div><div>ph: +91 98455 72696</div><div>skype: tdinkar</div></div></div></div></div></body></html>