Re: Q's about Obj-C
Re: Q's about Obj-C
- Subject: Re: Q's about Obj-C
- From: Ondra Cada <email@hidden>
- Date: Mon, 15 Oct 2001 19:43:24 +0100
Joe,
>
>>>>> Joe Chan (JC) wrote at Mon, 15 Oct 2001 12:52:42 -0400:
JC> >Actually, the language _NEVER_ requires message declaration.
JC> >
JC> >If you know plain C well, consider function headers. In ObjC,
JC> >it's _EXACTLY_
JC> >the same: the only difference is that an "unknown" function
JC> >would return an
JC> >int, whilst an unknown message would return an id (those are
JC> >convertible
JC> >anyway).
JC>
JC> I thought the unknown part only applies to return values, not function.
Ah, perhaps I misted the thing somewhat speaking of functions...
(i) for a moment, forget ObjC completely. We are in plain C, and we speak
functions. Now,
- you don't have to declare a function;
- function name is sufficient so as the proper function is called;
- you have to beware though that the argument types and return values are correct.
This is something you should know very well, in case you are an experienced
C programmer. Right?
(ii) now, let's forget C and functions, and let's focus on ObjC and
messages/methods:
- you don't have to declare a message/method (at _this_ abstraction level
it's the same);
- message name (ie. "foo:" or "alloc" or "writeToFile:atomically:") is
sufficient so that the proper method is found and called;
- you have to beware though that the argument types and return values are correct.
Actually, the "unknown part" (in case message is not declared) are types of
all the arguments and the return type. I'll get to that once more below.
JC> Then is it fair to say that the declarations of messages in .h
JC> is strictly speaking not required by the language? I'm still a
JC> little confused. For example is:
JC>
JC> @interface A : NSObject
JC> @end;
JC> @implementation A
JC> - (int) foo { /* new method */
JC> return 1;
JC> }
JC> @end
JC>
JC> legal?
Quite right!
JC> >id o;
JC> >[o foo:1]; // issues a warning, and compiles randomly (A) or (B)
JC>
JC> I thought that because the runtime selects the method, it won't
JC> really be randam, will it? It will either be calling A's or B's
JC> or forwarded (if it's setup to do so), right?
Well, you are right, but I tried to point out something different.
Yep, always it would select and call the correct method, ie. the correct A's
or B's implementation.
Though, there are some calling conventions. Let's say that arguments are
stored traditionally on stack (on PPC they are not, in fact). Now:
JC> >[(A*)o foo:1]; // converts 1 to double (A)
this would push a "double" (64 bits) in the FPU mantissa/exponent format;
JC> >[(B*)o foo:1]; // uses 1 as an integer (B)
this would push an int (32 bits) in the normal binary (0x00000001).
If we, for example, did
id o=[A new];
[(B*)o foo:1];
then the A's method would be properly selected and called, so far so good.
*BUT* it would read the topmost (well, more or less) 64 bits from stack, and
try to interpret it as a "double" value -- since something wuite different
was pushed, it would have a nonsensical result.
Right?
If you used only id-convertible values (ints, pointers, ids, ...), then this
problem would never occur.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc