[LRUG] The advantage of immutability?

[Stephen Best]

In every example I've seen immutability has certainly required more effort,
but I don't think this always correlates with more complexity. However, I
find people usually have their own idea of what simplicity looks like.

Given that we model a request / approval system using a single table of
requests with an `approved_at` field, what happens if a approval is
submitted twice, at different times or perhaps concurrently?

The obvious solution is to throw in an `if` statement checking whether
approval has already happened. Perhaps we would allow `approved_at` to be
overwritten multiple times (can of worms there). Maybe we could use a
database transaction to prevent it, then dependent on which isolation level
we choose this could block or raise an exception.

In future would it be desirable to know about multiple approvals? What
about if requirements change and multiple users must approve a request?

This is all hypothetical of course, but we never know what future
requirements will be. I would have to insist that none of the solutions I
suggested above sound simple at all. On the other hand choosing an
immutable, append only approach seems like more effort but I would feel
much better placed to answer the questions about edge cases and future
requirements.

Bestie.


On 10 Sep 2015, at 08:49, Jonathon Horsman <jonathon at arctickiwi.com> wrote:

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
>
>
_______________________________________________
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/89d3318c/attachment-0003.html>