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

Matthias Wessendorf matzew at apache.org
Tue Feb 4 08:01:39 EST 2014


consistency FTW


On Tue, Feb 4, 2014 at 1:55 PM, Corinne Krych <corinnekrych at gmail.com>wrote:

> Hello all,
>
> Time to bring back the topic, on the immutability vs mutable issue for
> memory (an espicially 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
> >
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/df599e87/attachment-0001.html 


More information about the aerogear-dev mailing list