[LRUG] The advantage of immutability?

[Jonathon Horsman]

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'".

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.

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?

I find jc's comment odd:

*So now that the problem is phrased in terms of wanting to manipulate
shared global state then mutability seems like the correct option.*

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?

Clearly I'm missing something - I appreciate your input.

Jonno

On 9 September 2015 at 19:21, Gerhard Lazu <gerhard at lazu.co.uk> wrote:

> Should a Request know or even care about its denial? Which parts of your
> app need to know about request denials?
>
> These questions are meant to open up the path to your answer. Simple
> Design by Corey Haines will help.
>
> I can only reinforce Roland's point: keep it simple.
>
> Gerhard
>
>
> On Wednesday, 9 September 2015, Jonathon Horsman <jonathon at arctickiwi.com>
> wrote:
>
>> Hey smart people
>>
>> Can you shed some light on why an immutable object is an advantage for a
>> web-based Ruby app?
>>
>> For example this app I'm working on has these Request things and a user
>> has the ability to deny a Request.
>>
>> So the user would click a button which performs a post to the Request
>> controller's deny action.
>> 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.
>>
>> However since this Request is an immutable object, I have to either:
>>
>> 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
>> or
>> 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.
>>
>> My knowledge of immutable objects originates with Java Strings which I
>> understand makes sense for performance and memory management reasons.
>> I don't think this applies here though?
>>
>> Thanks!
>>
>> Jonno
>>
>
>
> --
>
> ------------------------------
> Twitter <http://twitter.com/#!/gerhardlazu> Github
> <https://github.com/gerhard> Blog <http://gerhard.lazu.co.uk/>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/882aa75e/attachment.html>