Professional Web Applications Themes

ObjC: print01(), print02(), print03()...? - Mac Programming

From dev CD dox: "The messaging routine has access to method implementations only through selectors, so it treats all methods with the same selector alike. It discovers the return type of a method, and the data types of its arguments, from the selector. Therefore, 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." Having a wee bit of trouble with this. I take the above to mean that once I write a function called "print()" for my program, there can never ...

  1. #1

    Default ObjC: print01(), print02(), print03()...?


    From dev CD dox:

    "The messaging routine has access to method implementations only through
    selectors, so it treats all methods with the same selector alike. It
    discovers the return type of a method, and the data types of its
    arguments, from the selector. Therefore, 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."

    Having a wee bit of trouble with this. I take the above to mean that
    once I write a function called "print()" for my program, there can never
    be a "print()" even for another class, which doesn't take identical
    params & return values.

    Id est, because classes are all global in ObjC, (no namespace), and
    because a message can be "sent" to any object, (and just about
    everything is an object), essentially EVEN MEMBER FUNCTIONS are
    pragmatically all global. Right? Because the issue is not, as in C++,
    whether that class has such a member function.

    In still other words, not only is function overloading prohibited in a
    class, it is prohibited AMONG ALL CLASSES of an executable. Because
    this might include libraries of classes which I didn't write, my print()
    might clash with the print() of a library... ???

    So my program (let's say) has a Debug::print( error ), and I link with
    a lib which has 3DGraphicsLib::print( model )... At runtime I might get
    a bus error???

    Also, the above blurb seems to say that the params & return types are
    encoded in the SEL, like a C++ mangled name, then it also completely
    refutes that idea. Aargh.

    I have the feeling I'm missing something here, but I certainly can't
    tell what it is. Can someone clarify this, please?

    Eden
    Eden Guest

  2. #2

    Default Re: ObjC: print01(), print02(), print03()...?

    In article <lafn.org>,
    Eden Smallwood <pg> wrote:
     

    That's right, except for the aforementioned allowance for
    statically-typed objects--but the static type better be right. I.e. if
    you have '-(void)print:(double)' in class Foo, and '-(void)print:(int)'
    in class Bar, you will be OK as long as the compiler can see the method
    declarations *and* the static types at the point that the message is
    sent. If you try to send 'print' to an id, you are in trouble.

    You can also probably get away with just making sure that the parameters
    all have the same 'sizeof', but that is likely to break as the G5 and
    64-bit addressing moves into the forefront.
     

    Yes.

    (This space reserved for someone to chime in that objective-c does not
    have member functions.)
     

    Yep.
     

    Yep.

    (This space reserved for someone to freak out about the C++-style
    scoping notation.)
     

    You're not missing a thing. Objective-c's half-assed globalization of
    method names/signatures is about as wrong as wrong can be. Lisp got this
    right; if the names are global, then the functions don't really belong
    to the class at all!

    -Chad
    Chad Guest

  3. #3

    Default Re: ObjC: print01(), print02(), print03()...?

    On Tue, 6 Jul 2004, Eden Smallwood wrote:
     

    That sounds like a very inaccurate description. The messaging routine has
    *no idea* about argument types and return types at all. It simply trusts
    that the caller and the callee agree. Normally this is done by the
    compiler, which looks up the types at compile time. This is the cause for
    the warnings that appear of you call a method that doesn't exist, or if
    you forgot to #import the right header; if the compiler can't see the
    method declaration, it doesn't know what the types are, and it will have
    to guess. If it guesses wrong, bad things can happen.

    It's entirely possible to declare two classes that have methods with the
    same name but different types; Cocoa itself does this, for example with
    the -length message. In this case, if you send that message to an object
    that isn't statically typed, the compiler will again warn you and make a
    guess. For this, you need to statically type the receiver of the message,
    either by declaring it statically or by casting.

    That is the only conflict.
    Michael Guest

Similar Threads

  1. ObjC Nubie:Basic Drawing
    By John in forum Mac Programming
    Replies: 4
    Last Post: February 16th, 11:09 PM
  2. Objc Nubie: Errors Errors Errors
    By John in forum Mac Programming
    Replies: 8
    Last Post: February 16th, 07:30 PM
  3. Using gcc/ObjC from shell, which libraries are needed?
    By David in forum Mac Programming
    Replies: 2
    Last Post: January 3rd, 07:29 PM
  4. Replies: 2
    Last Post: October 6th, 06:51 PM
  5. Python and ObjC
    By Wezzy in forum Mac Programming
    Replies: 3
    Last Post: September 16th, 05:48 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139