Cocoa mail archive
Re: Dynamic message typing problem
FROM : Michael Vannorsdel
DATE : Sat May 17 00:06:40 2008
Just to add, it's generally important to include compiler warnings
with your problem description as they provide valuable clues. The
compiler issues warnings when something doesn't look right, make
sense, or lacking information. Usually the compiler will make guesses
and assumptions as to what you want the code to do, which is not
always correct. The binary will build but may not function as intended.
On May 16, 2008, at 3:34 PM, Bill Bumgarner wrote:
>> Thanks Scott.
>>
>> Yes, the file did not include declaration of AnonTargetClass.
>> I did see compiler warnings but I've always seen these on the G4
>> and the system worked perfectly well.
>
> An almost universal rule of Mac OS X programming: If you see a
> compiler warning, you are doing something wrong.
>
> Fix the compiler warnings first (and correctly -- i.e. casting willy-
> nilly is not a fix) and then address the real problems within your
> code that remain.
>
> In this case, that the code worked on any platform is merely a
> coincidence brought about by the architecture of said platform and
> the compiler.
>
>> Any idea where I should look to find ways of correcting this code?
>> Does one need to store the SEL or something like that?
>
> You need to declare -printFloat: someplace that the compilation of
> the above will see the declaration and will interpret the arguments
> correctly.
>
> This may be as simple as #import'ing an appropriate header file. A
> more precise fix would be to not use (id) as the parameter type, but
> to declare the type explicitly. This would have the side effect of
> requiring that you #import the class definition (or use @class,
> which won't solve the problem).
>
>> Also do you have any idea of where I could look for a description,
>> (possibly with an example ?) of the standard approach to dynamic
>> typing when it is not possible to include the header of the called
>> object, for instance when having to avoid circularity in header
>> file definition or the object is being defined on the fly?
>
> Circularity of includes is easily addressed by using @class in the
> header portion to forward declare classes such that the circularity
> is avoided.
>
> As per the implementation, circularity of includes should not be any
> more of an issue than in headers. It is simply a matter of
> including the files in the right order.
>
> Which, of course, is a pain in the butt and for which Xcode projects
> offer project headers and precompiled headers such that you can have
> one master (or set of masters) header(s) that are included in your
> implementation files instead of mentioning individual header files.
>
>> Even so I'm puzzled.
>> I thought cocoa was designed to allow dynamic typing i.e. where the
>> class of the called object is not declared in the calling file and
>> that the run time resolution process involves searching a method
>> table for a match of the method call and by this means, if the
>> method name is unique, the types of the parameters are determined.
>> Indeed is this not just the standard messaging mechanism? Or is
>> this why I sometimes have the impression that cocoa encourages us
>> to pass Objects as parameters to everything? The Kochan
>> "Programming in Objective-C" does note the possibility of conflict
>> when method names are not unique but here the method is unique. and
>> exactly, even if we are passing object ids these will eventually
>> need to be resolved so that brings us back to square one......
>
> The runtime resolution process is very good about figuring out what
> method to call dynamically at runtime, but Objective-C is still a C
> derived language. Thus, it benefits from all of the efficiencies
> and suffers from all of the idiosyncrasies of C.
>
> In this case, you haven't given the compiler enough information
> about the size and encoding of the parameters. By the time the
> runtime sees the method call, the compiler has already had its way
> with the arguments -- potentially promoting the float to an int or
> otherwise losing information.
>
> You need to make the method declaration visible to the compiler to
> make this work.
>
>> P.S.
>> Does this problem of mine qualify as an example of the difficulties
>> in learning cocoa recently discussed on this list?
>
> Not really. Ignoring compiler warnings is a common mistake that
> many many folk make when first learning C, Objective-C or C++,
> regardless of targeted programming environment.
>
> The tools are trying to help you by pointing out where you have done
> something that is incompletely specified. Fix the warning, most of
> your problems are likely to go away.
DATE : Sat May 17 00:06:40 2008
Just to add, it's generally important to include compiler warnings
with your problem description as they provide valuable clues. The
compiler issues warnings when something doesn't look right, make
sense, or lacking information. Usually the compiler will make guesses
and assumptions as to what you want the code to do, which is not
always correct. The binary will build but may not function as intended.
On May 16, 2008, at 3:34 PM, Bill Bumgarner wrote:
>> Thanks Scott.
>>
>> Yes, the file did not include declaration of AnonTargetClass.
>> I did see compiler warnings but I've always seen these on the G4
>> and the system worked perfectly well.
>
> An almost universal rule of Mac OS X programming: If you see a
> compiler warning, you are doing something wrong.
>
> Fix the compiler warnings first (and correctly -- i.e. casting willy-
> nilly is not a fix) and then address the real problems within your
> code that remain.
>
> In this case, that the code worked on any platform is merely a
> coincidence brought about by the architecture of said platform and
> the compiler.
>
>> Any idea where I should look to find ways of correcting this code?
>> Does one need to store the SEL or something like that?
>
> You need to declare -printFloat: someplace that the compilation of
> the above will see the declaration and will interpret the arguments
> correctly.
>
> This may be as simple as #import'ing an appropriate header file. A
> more precise fix would be to not use (id) as the parameter type, but
> to declare the type explicitly. This would have the side effect of
> requiring that you #import the class definition (or use @class,
> which won't solve the problem).
>
>> Also do you have any idea of where I could look for a description,
>> (possibly with an example ?) of the standard approach to dynamic
>> typing when it is not possible to include the header of the called
>> object, for instance when having to avoid circularity in header
>> file definition or the object is being defined on the fly?
>
> Circularity of includes is easily addressed by using @class in the
> header portion to forward declare classes such that the circularity
> is avoided.
>
> As per the implementation, circularity of includes should not be any
> more of an issue than in headers. It is simply a matter of
> including the files in the right order.
>
> Which, of course, is a pain in the butt and for which Xcode projects
> offer project headers and precompiled headers such that you can have
> one master (or set of masters) header(s) that are included in your
> implementation files instead of mentioning individual header files.
>
>> Even so I'm puzzled.
>> I thought cocoa was designed to allow dynamic typing i.e. where the
>> class of the called object is not declared in the calling file and
>> that the run time resolution process involves searching a method
>> table for a match of the method call and by this means, if the
>> method name is unique, the types of the parameters are determined.
>> Indeed is this not just the standard messaging mechanism? Or is
>> this why I sometimes have the impression that cocoa encourages us
>> to pass Objects as parameters to everything? The Kochan
>> "Programming in Objective-C" does note the possibility of conflict
>> when method names are not unique but here the method is unique. and
>> exactly, even if we are passing object ids these will eventually
>> need to be resolved so that brings us back to square one......
>
> The runtime resolution process is very good about figuring out what
> method to call dynamically at runtime, but Objective-C is still a C
> derived language. Thus, it benefits from all of the efficiencies
> and suffers from all of the idiosyncrasies of C.
>
> In this case, you haven't given the compiler enough information
> about the size and encoding of the parameters. By the time the
> runtime sees the method call, the compiler has already had its way
> with the arguments -- potentially promoting the float to an int or
> otherwise losing information.
>
> You need to make the method declaration visible to the compiler to
> make this work.
>
>> P.S.
>> Does this problem of mine qualify as an example of the difficulties
>> in learning cocoa recently discussed on this list?
>
> Not really. Ignoring compiler warnings is a common mistake that
> many many folk make when first learning C, Objective-C or C++,
> regardless of targeted programming environment.
>
> The tools are trying to help you by pointing out where you have done
> something that is incompletely specified. Fix the warning, most of
> your problems are likely to go away.
