[LRUG] The advantage of immutability?

[Stephen Best]

I would add thread safety to the list which may or may not be important to
you depending on your interpreter and deployment method of choice, but all
things equal it's a desirable quality for your software to have.

If you're attempting to model a mutable data model with a set of immutable
objects you may find that the trade offs don't work in your favour. You may
want to reconsider how you persist an accepted request, perhaps you could
store 'concents' separately and not mutate your 'request' records. This
would make an approach where you do something along the lines of compose an
accepted request object with a request and a consent and send that to a
repository which persists them a more obvious solution.


Stephen Best

theaudaciouscodeexperiment.com
github.com/bestie
@thebestie

On 9 September 2015 at 16:25, Jonathon Horsman <jonathon at arctickiwi.com>
wrote:

> Hey thanks for the responses.
>
> To summarise the main reason appears to be to avoid unexpected changes
> being made on an object as it is passed around.
>
> I'm struggling a bit to envisage when this might occur in the relatively
> simple sorts of apps I'm working on.
>
> 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.
> If it does surely that's a major bug in the logger or a failure of the
> tests to pick that up?
>
> 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
> The process to handle that update in an immutable system would be either:
>
> Update email address of user with ID 1234
> Update first name of user with ID 1234
> Update last name of user with ID 1234
> etc...
>
> OR:
>
> Read existing user 1234 from database
> Merge new (changed) attributes and unchanged attributes the user doesn't
> have permission to change, e.g. creation date.
> Create a new user object with the merged attributes
> Persist new object (with same ID) to database
> Pass back new object to caller to be rendered
>
> 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.
>
> 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.
>
> Thanks again for your responses.
>
> On 9 September 2015 at 11:43, Roland Swingler <roland.swingler at gmail.com>
> wrote:
>
>> > why an immutable object is an advantage
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Thanks,
>> Roland
>>
>> On Wed, Sep 9, 2015 at 11:25 AM, 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
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20150909/200ad09b/attachment.html>