Re: Keyed decoding of geometry

[Richard Frith-Macdonald]

On 24 Jan 2004, at 17:06, Fred Kiefer wrote:

> Hi Richard,
>
> are you sure about the way you are decoding points, rects and size? I 
> only have one keyed NIB file, that sombody has mailed me and here the 
> geometry looks different. For example a rectangle is stored as:

First ... this is still very much a work in progress.
I'm using the xml format in my test programs, and archives in the old 
OpenStep style format probably will need some work later as it doesn't 
support all the datatypes used (I'm not sure if/how MacOS-X supports 
that format).  I've updated the code to use xml format by default for 
now.

> <string>{{332, 76}, {78, 32}}</string>
>
> What I would have expected were methods in the style:
>
>
>
> - (NSSize) decodePointForKey: (NSString*)aKey
> {
>   NSString *string = [self decodeObjectForKey: aKey];
>
>   if (string == nil)
>     {
>       retrun NSMakePoint(0, 0);
>     }
>   else
>     {
>       return NSPointFromString(string);
>     }
> }
>
> - (NSSize) decodeSizeForKey: (NSString*)aKey
> {
>   NSString *string = [self decodeObjectForKey: aKey];
>
>   if (string == nil)
>     {
>       retrun NSMakeSize(0, 0);
>     }
>   else
>     {
>       return NSSizeFromString(string);
>     }
> }
>
> - (NSRect) decodeRectForKey: (NSString*)aKey
> {
>   NSString *string = [self decodeObjectForKey: aKey];
>
>   if (string == nil)
>     {
>       retrun NSMakeRect(0, 0, 0, 0);
>     }
>   else
>     {
>       return NSRectFromString(string);
>     }
> }
>
> Or are your methods for something completely different? If so, could 
> we still add the above methods as a GNUstep extension?

I haven't added encodePoint:forKey: etc yet (don't know how I missed 
them).
What I added this morning was support for the old API encodePoint: etc.
The methods I've added, I've also checked on MacOS-X ... so the 
encodePoint: method simply encodes two floats, but the 
ecodePoint:forKey: method may well do something different.

> And I also tried to write a few sample decoding methods based on that 
> NIB file. I made specific methods out of them, so that it will be 
> easier to keep them a bit apart from our current decoding code. 
> Actually I would like to see some method like the follwoing on 
> NSObject so we dont have to mix the different code in one method:
>
>
> - (id) initWithCoder: (NSCoder*)aCoder
> {
>   if ([aCoder allowsKeyedCoding])
>     {
>         self = [self initWithKeyedCoder: aCoder];
>     }
>     else
>     {
>         // call old decoder code, for which I don't have a great name
>     }
> }

Maybe, on the other hand, keeping the two together might be considered 
a virtue ... certainly if the code involved is small.

> And now to show you how easy some base classes could be decoded:
>
> @implementation NSArray (NSKeyedCoding)
>
> - (id) initWithKeyedCoder: (NSCoder*)aCoder
> {
>   NSArray *array = [aCoder decodeObjectForKey: @"NS.objects"];
>
>   [self initWithArray: array];
>   return self;
> }
>
> @end
>
> @implementation NSSet (NSKeyedCoding)
>
> - (id) initWithKeyedCoder: (NSCoder*)aCoder
> {
>   NSArray *array = [aCoder decodeObjectForKey: @"NS.objects"];
>
>   [self initWithArray: array];
>   return self;
> }

I'm not sure this is right ... I think you are looking at something 
I've not impemented yet (and not even fully investigated).
It appears that the keyed archiver implements 
-encodeArrayOfObjCType:length:at: by creating a temporary object of a
private class in which to encapsulate the array, then encodes that 
temporary object.  The temporary object encodes itsself
by writing various items with names like 'NS.objects'
To implement this properly, I need to figure out exactly how the 
private class (_NSKeyedCoderOldStyleArray) encodes itsself for arrays 
of different types of data.
 Quite possibly there are other things missed ... I haven't played with 
it to see how MacOS-X implements encodeValuesOfObjCTypes: for instance.