Re: Encoding infinite loops
Re: Encoding infinite loops
- Subject: Re: Encoding infinite loops
- From: Chris Kane <email@hidden>
- Date: Tue, 22 May 2007 08:32:25 -0700
On May 22, 2007, at 1:10 AM, Uli Kusterer wrote:
On 21.05.2007, at 18:47, Chris Kane wrote:
Consider for a moment an object unarchiving itself. The
unarchiver has created the object for that reference in the
archive and is initializing it. The object unarchives a bunch of
other state, some of which is more objects. If one of the
subobjects has a reference to the original object, and unarchives
that, the unarchiver happily gives it the object which it has
already created for that object -- but in this case note that that
object is still initializing itself. This can create two sorts of
problems, but in the lucky case everything unwinds and things work
out and the recursive reference has been restored by the unarchiver.
Err... you mean this class is documented as handling several
references to the same object ... but doesn't?
Can't you just keep a original pointer -> object dictionary (which
contains the object that actually was unarchived, not any temporary
object that might have been replaced) and just look up each object
in the graph that way? This is a problem that's been solved so many
times over that I'm kind of embarrassed that a framework like Cocoa
doesn't handle this, and moreover is unable to fail gracefully in
that case instead of unarchiving garbage objects.
I think you may have missed the point of the problem. Here's a
different way to view it: the unarchiver has no way to go back and
replace all the pointers to an object that it has already given out,
when an object is replaced later. The unarchiver could provide a
mechanism, but every unarchivable class has to also participate in
order to handle potential updates, which is where things fall apart
-- the unarchiver can't mandate such participation (for backwards
compatibility, for example).
Of course to handle several references to the same object, even
recursive ones, the unarchiver has to keep a couple reference ->
object dictionaries. But the references aren't original pointers.
Keeping an original pointer -> eventual pointer dictionary doesn't
work in practice because original objects are freed during
unarchiving and the memory pointers can get reused for other
objects. Of course, the unarchiver keeps a retain on the objects
being initialized as they are unarchived. But that doesn't stop
classes out there from using [self dealloc] and [super dealloc] or
even lower-level things (thus bypassing the reference counting) from
within their initWithCoder: method when they are returning a new object.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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