[aerogear-dev] Mutable vs Immutable for AGMemoryStore and AGPropertyStore

Corinne Krych corinnekrych at gmail.com
Tue Feb 4 08:33:13 EST 2014


Hello all,

Time to bring back the topic, on the immutability vs mutable issue for
memory (an especially plist) storage.
read method should return an immutable object. Make it all immutable will
help consistency.
thoughts?
++
Corinne

On 25 Nov 2013, at 23:41, Corinne Krych <corinnekrych at gmail.com> wrote:

I see actually 2 correlated problems in the described use case:

1. Immutability. [store readAll] return a mutable object I can then modify
without using 'save' method. In Objective-C, mutability is a strong concept
[1].
But then immutability is not well supported in all languages...
unmodifedCollection in Java not quite the same than immutable.
I see 2 options:
a) make slight API changes to cater both way like:
void save(T item)
could be replaced by
T save(T item)
b) change only iOS implementation and accept slight differences as each
language idiomatic
2. PList Storage dump the whole content of memory storage in one file
whether you go for save one element or save all element. But if we have
immutability then it wouldn't be such a problem.

++
Corinne
[1]
https://developer.apple.com/library/mac/documentation/general/conceptual/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html


On 25 November 2013 22:17, Christos Vasilakis <cvasilak at gmail.com> wrote:
This effect is most visible in the Memory storage implementations, since
the mutable objects returned can be modified without the user asks for an
explicitly 'save' operation. In the scenario described, regardless if you
did save or not, a later 'read' operation on the store, would have returned
a possible modified object (done outside the store periphery).

Other store types (aka SQL) don't suffer from this, since all read
operations request the last state from permanent store.

It all comes to this:
a 'read' operation on a store _must_ guarantee to return the state of an
object previously 'saved'. If the memory storage implementation fails on
it, then 'read' should be fixed using each platform mutability semantics.
If not mistaken, I believe this effect of mem storage is exhibited on our
other platforms too.

-
Christos

> On Nov 25, 2013, at 3:24 PM, Corinne Krych <corinnekrych at gmail.com> wrote:
>
> Hello Guys,
>
> Using AGPropertyListStorage in Xmas app [1], I run into this interesting
issue:
>
> In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable
copy of the NSArray and I save encrypted data in it
> I decrypt some of the data in memory BUT I actually don't want those to
be saved decrypted into permanent storage.
> And then let's say I add some more data with encrypted value then I save
this dato to my AGProperListStorage. Just this one.
> But surprise, if I look in my permenet storage, I see my newly data
encrypted but the other data I ecrypted in memory were saved decrypted
>
> What happened?
> In one word: shallow mutable copy of NSArray.
> My mutable array still point to original MSMutableDictionary and when
saving one data to permanent storage the all memory is dumped into plist
resulting in decrypted value to be stored.
>
> How did I fixed it?
> Using deep mutable copy see in [2].
>
> In AGMemoryStorage (and its inherited AGPropertyListStorage) we use
NSMutableDictionary because you can save item (represented as Key/Value
with NSMutableDictionary) without id, the store will take care of
generating this id and assign it back into the item.
>
> Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary
is misleading because you can actually do
> NSArray myArray = [store reallAll]
> and then modify the contain of the memory storage without using save.
>
> That experience brings the topic whether it's a good pratice to use
mutable object
>
> Options
> - option1: stick to immutable objects whithin the AGStore and let the
save method return an immutable NSDictinary containing the item
> - option2: leave it as it is, responsability of user to do deep copy
> - others ?
>
> Personal Preference go for option1 which I found less confusing.
>
> ++
> Corinne
> [1]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md
> [2]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas/Classes/Controller/AGGiftListCollectionViewController.m#L66
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/9b32575b/attachment.html 


More information about the aerogear-dev mailing list