Re: Q's about Obj-C
Re: Q's about Obj-C
- Subject: Re: Q's about Obj-C
- From: "Philippe Mougin" <email@hidden>
- Date: Mon, 15 Oct 2001 19:58:24 +0200
>
3. About the fact that all method of the same name needs to
>
receive the same argument and return types. I'm a little
>
confused by that. Does that apply only to the case of overriding
>
existing method? Say if I have two classes A and B that belongs
>
to different class hierarchies, and they both declare method foo:
>
>
@interface A : ParentOfA
>
>
-(int)foo: (float)arg;
>
>
@end
>
>
@interface B : ParentOfB
>
-(void)foo: (int)arg;
>
@end
>
>
Is this illegal? If so, how does one go about ensuring unique
>
method names within a potentially large class hierarchy?
This is perfectly legal. But the big difference with C++ or Java you should
keep in mind is that the Objective-C compiler will not infer which signature
to use based on the type of the actual parameters you pass in your code at
the point of invocation of the method.
This has far reaching implications.
First, it means that you should call such methods only on statically typed
receiver (i.e. not receiver typed as id). As the doc states "except for
messages sent to statically typed receivers, dynamic binding requires all
implementations of identically named methods to have the same return type
and the same argument types". When you use a statically typed receiver, the
compiler is able to determine the right signature and thus to generate the
correct stack layout. In most common development case, you will find that
the compiler helps you a lot to deal with this issue. Notably, when the
compiler is not able to safely determine which signature to use, it will
issue a warning to let you know there is an ambiguity (in addition, the
compiler will randomly handpicks one of the candidate signatures and goes on
with that. You'd better check that the chosen signature is the good one in
order to avoid crash or corrupted behavior at run-time).
Second implication: a class can't easily define multiple methods with the
same name but different argument types or return types. This is because
statically typing the receiver to its specific class will not help the
compiler in this case. A solution possible solution, using different
protocols to declare the different methods and statically typing the
receiver to the right protocol may works (not tested) but would probably be
too much complex.
Litle note about Java: the situation is basicaly the same in Java regarding
return type: you can't have a class with two methods having the same name,
the same arguments types, and differents return types.
>
4. What makes a class an abstract class? In C++, that's caused
>
by a pure virtual function, but there doesn't seem to an
>
equivalent in Obj-C.
A pure abstract class with no instance variable and no method
implementations (just methods declarations) is done in Objective-C using a
Protocol. For other cases, there is no equivalent to pure virtual functions.
In practice, you will see this is neither a concern nor a limitation.
Basicaly, with Objective-C, you can subclass any class and overide any
method, without having to specificaly allows this at the superclass level.
Phil