On Tue, Feb 4, 2014 at 1:55 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
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
On 25 Nov 2013, at 23:41, Corinne Krych <corinnekrych(a)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
> 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
> 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.
> On 25 November 2013 22:17, Christos Vasilakis <cvasilak(a)gmail.com>
> 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.
> > On Nov 25, 2013, at 3:24 PM, Corinne Krych <corinnekrych(a)gmail.com>
> > Hello Guys,
> > Using AGPropertyListStorage in Xmas app , I run into this
> > 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 .
> > 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
> > 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
> > 
> > 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> aerogear-dev mailing list
aerogear-dev mailing list