[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[patch #6286] NSBezierPath encode/decode improperly implemented
From: |
Christopher Wojno |
Subject: |
[patch #6286] NSBezierPath encode/decode improperly implemented |
Date: |
Tue, 27 Nov 2007 18:07:26 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.9) Gecko/20071117 Firefox/2.0.0.9 |
Follow-up Comment #2, patch #6286 (project gnustep):
> In your error message I can see that an NSKeyedArchiver gets
> used. As far as I can see, your patch doesn't implement
> the missing keyed archiving for NSBezierPath, so how does it
> help you?
NSKeyedArchiver/NSKeyedUnarchiver (and the non-keyed archivers) implicitly
rely on participating classes implementing the NSCoding protocol, which is
implemented in NSBezierPath in [NSBezierPath -encodeWithCoder:] and
[NSBezierPath initWithCoder:]. This is how NSArchivers are able to construct a
recursive graph of the instance variables of the NSBezierPath when the
archiving is requested. When the archivers are invoked, they will call those
two functions (which I have modified).
> In my code NSBezierPathElement is always an enumeration, why
> would the encoding stuff need the additional hint that it
> really is an enum?
I am at a loss for you there. I am using:
gcc (GCC) 3.4.6 [FreeBSD] 20060305
and
gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
and my patch corrects the aforementioned error in both.
> How should that make any difference? Apart from readability of
> course. It may make a difference for keyed encoding though.
NSPoint is a struct. The Exception explained that Obj-C does not know how to
encode structs. So I had assumed it would also cause problems. However, in
light of the source of the encodePoint (which I did not look at because I have
used it before with success and reliability), there is no point to the change
other than it, as you said, improves readability and provides tighter typing
information. I care only that the exception is no longer thrown. If you wish
to excise this portion of the patch, you may do so. It is, after all,
ultimately at your discretion. I must say that, given the exception message, I
am thoroughly dumbfounded as to why @encode(NSPoint) works but the enum did
not.
> It could well be that your patch works around limitations of
> the keyed encoding in base. We better should know about these,
> before we hide them.
I am afraid I do not know what you mean. I have only been working with
GNUstep for little more than a week on a project for school.
The @encode(enum ID) is definitely a problem. I hope this fix may be applied
to other places as well.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/patch/?6286>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/