Re: Best design pattern for un-archiving instances of shared resources?
Re: Best design pattern for un-archiving instances of shared resources?
- Subject: Re: Best design pattern for un-archiving instances of shared resources?
- From: "Barry Wark" <email@hidden>
- Date: Sun, 21 Oct 2007 00:25:18 -0700
By going with the strategy described by David, I was able to make the
change stick, even if the decoding was done with an unarchiver that
didn't have the delegate set. It seems that there are two approaches
possible here... the more global approach that David described and the
local approach that you describe. Since this was a refactor of some
existing code, I went with the global option.
One last question for the gurus: it appears that awakeAfterUsingCoder
should follow the memory management rules of an init method, namely
returning a retained object (as opposed to an autoreleased object as
you might expect from the standard idiom of methods that do not
allocate the object). Can someone confirm this?
Thanks for all the help!
Barry
On 10/20/07, Uli Kusterer <email@hidden> wrote:
> Am 19.10.2007 um 02:06 schrieb Barry Wark:
> > So, question for the gurus:
> > Is there a better pattern for solving the problems I've outlined
> > above, particularly one that doesn't require a similar hack for every
> > subclass?
>
> Did you check whether NSUnarchiver and NSArchiver have any useful
> methods? The NSArchiverCallback informal protocol for NSObject sounds
> like it could solve your problem or alleviate it a bit. It seems to
> allow providing a different object to archive in place of the current
> object.
>
> NSUnarchiver also has -replaceObject:withObject:, which looks like
> it's the opposite.
>
> I hope that hasn't been mentioned yet, I haven't yet managed to go
> up-thread on this one.
>
> Cheers,
> -- M. Uli Kusterer
> http://www.zathras.de
>
>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden