[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)

From: Kazunobu Kuriyama
Subject: Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)
Date: Thu, 22 Jan 2004 08:43:33 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Richard Frith-Macdonald wrote:


The NSCoder API is extended so that  encodeWithCoder: and initWithCoder:
methods can  determine whether they are being encoded with a keyed
archiver or an old style archiver ... so they can behave differently for each.


The GNUstep base library provides runtime macosx compatibility setting
via the user defaults system ... so encodeWithCoder: and initWithCoder:
methods are also able to behave differently on the basis of these settings.


It seemed obvious to me that when adding keyed archiver support to
coding/decoding methods, the existing code would be retained for
non-keyed archives,

I think this is right.

while new keyed archive code would generally
be written to be MacOS-X compatible.

This is the point I'd like to make sure of. Does "be MacOS-X compatible" mean that archives resulting from the new GNUstep's keyed archiver could be used with both GNUstep and MacOS-X, or, its format (e.g., the names of keys) would be merely the
same as that of MacOS-X?

If it means the latter, the work for modifying initWithCoder:/encodeWithCoder: is expected to be tedious but straightforward.
For the former, however, these methods must inherently know the mapping from
a GNUstep's object graph to the corresponding MacOS-X's one and vice versa,
which I think is the point you suggested when you replied to my note on
the statistics.  Dealing with the mappings leads to the problems Gregory
pointed out.

Though I rather prefer the former compatibility if possible, I'm not sure how
the difficulty is overcome.  That's why I made a bitter compromise from the
beginning.  Too soon to give it up?

If there is a pressing need for keyed archive support to be added to
a class in a non-macosx-compatible manner, the incompatible version
could be controlled by the user defaults system.   My guess is that
this would rarely be necessary ... but that is just a guess, I don't think we will really know until we try writing new coding/decoding stuff.

I don't think anybody likes an avoidable non-compatiblity. IMHO, the problem
is rather a matter of feasibility and maintenability.

So as far as I can see, adding keyed archiving gives us the opportunity
to move towards portable/compatible archives without breaking any
existing stuff.

Indeed, it's a good opportunity.

- Kazunobu Kuriyama

reply via email to

[Prev in Thread] Current Thread [Next in Thread]