Re: Newbie Q about NSCoder
Re: Newbie Q about NSCoder
- Subject: Re: Newbie Q about NSCoder
- From: Charlton Wilbur <email@hidden>
- Date: Wed, 21 Sep 2005 06:58:06 -0400
On Sep 21, 2005, at 5:11 AM, email@hidden wrote:
Consider the following example (from Aaron Hillegass' book)
-(id) initWithCoder : (NSCoder*) coder {
....
[self setPersonName : [coder decodeObject]];
[coder decodeValueOfObjCType:@encode(float)
at:&expectedRaise];]
....
}
where the class considered (called Person) has two instance
variables personName and expectedRaise, and two methods
-setPersonName : (NSString*) s;
-setExpectedRaise : (float) f;
My questions are :
- what is exactly the type of the value [coder decodeObject] in the
code above ? If we look at the signature of the setPersonName
method, it seems that its type is NSString*. But it's just a
deceiving feature of Objective-C syntax, right ? The type of
[coder decodeObject] is simply id ; [coder decodeObject] is a big
machine which given a class and an instance produces the
corresponding value.
The type is, as you guessed, an id. The object-related type
information that you provide in your code, at least in the form
(NSString *) is used at compile-time so that the compiler can
optimize things and warn you when you're doing something wrong.
- If so, why is it not used uniformly in each case ; i.e, could the
two lines above be replaced with
[self setPersonName : [coder decodeObject]];
[self setExpectedRaise : [coder decodeObject]];
Because floats are not objects. The coder can't tell that it should
decode a float, and -setExpectedRaise: expects a float, not an
object. On the other hand, if you used an object type, such as by
storing the raise as an NSNumber, and you thus had the method
- setExpectedRaise: (NSNumber *) f;
then you could use the same code in both cases.
There's a lot of extra stuff that goes along with being an object,
including introspection: the knowledge of what class you belong to,
what selectors you respond to, and the like. NSString objects, for
instance, know how to serialize themselves for NSCoding, so that you
can just say [coder encodeObject: stringObject]; and the coder can
query the string object, find out that it is a string, and ask it to
provide an encoded archive representation of itself, including the
information in that encoding that it is an NSString object. When you
attempt to decode the NSString object, in addition to its value, the
coder finds the information that it is an NSString object, and thus
you don't need to tell the coder what type you expect.
Floats, on the other hand, don't know that they're floats, and so
when you want to encode them, you have to tell the coder that they
are floats. There's also no introspection information available in
the encoded archive, so you need to tell the coder that you're
expecting a float at that point. There could have been information
stored in the archive to that effect, but the programmer needs to
know to expect a float and not an object, and so it wouldn't have
done much practical good except to issue appropriate warnings at
runtime when the programmer did something wrong.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden