FROM : Rob Ross
DATE : Sat Jul 08 03:15:57 2006
>
> NSString *str = [[NSData alloc] init];
>
> because both `NSData' and `NSString' have `init' methods, and
> `init' methods return an object of type `id', which is NOT
> statically typed.
>
This looks like the kind of bug that would be easy to make,
especially with class names that are very similar. I guess you won't
find out until you send the object a message at runtime that it can't
process; then you'd have to hunt back through the stack trace to see
how you declared the object. I suppose in practice, it wouldn't be
that hard to debug this kind of error.
> For more egregious violations, like for example ...
>
> Cat *cat = [[Cat alloc] init];
> [cat bark];
>
> ... the compiler will throw up a warning and tell you that `cat'
> may not respond to the selector `bark'.
>
Well I'm glad at least it does that!
>
>
>> So my understanding is you can have the best of both worlds. Or
>> have I misunderstood something?
>>
>
> Not quite. Objective-C is pretty well entrenched in the runtime.
>
> You have to remember that you're NOT actually "calling a method"
> when working with Objective-C objects. You are sending them
> messages. Think about it this way. If language objects are people,
> then C++ objects are basically puppets. You don't tell them to do
> something; you just pull the string, and they do it. Objective-C
> objects are more independent. You TELL them that you'd like
> something done, and they'll do it if they can.
> --
>
That's interesting, because I remember a point long ago when I was
first learning OO programming (in C++), that I understood the concept
of "message passing", but that C++ didn't really implement that (nor
does Java): you're invoking a method, not passing a message. I was
always puzzled by the definition because the languages I used didn't
really seem to behave as described. It's nice to finally meet a
language that does what I intuitively understood "message passing" to
be.
Rob
DATE : Sat Jul 08 03:15:57 2006
>
> NSString *str = [[NSData alloc] init];
>
> because both `NSData' and `NSString' have `init' methods, and
> `init' methods return an object of type `id', which is NOT
> statically typed.
>
This looks like the kind of bug that would be easy to make,
especially with class names that are very similar. I guess you won't
find out until you send the object a message at runtime that it can't
process; then you'd have to hunt back through the stack trace to see
how you declared the object. I suppose in practice, it wouldn't be
that hard to debug this kind of error.
> For more egregious violations, like for example ...
>
> Cat *cat = [[Cat alloc] init];
> [cat bark];
>
> ... the compiler will throw up a warning and tell you that `cat'
> may not respond to the selector `bark'.
>
Well I'm glad at least it does that!
>
>
>> So my understanding is you can have the best of both worlds. Or
>> have I misunderstood something?
>>
>
> Not quite. Objective-C is pretty well entrenched in the runtime.
>
> You have to remember that you're NOT actually "calling a method"
> when working with Objective-C objects. You are sending them
> messages. Think about it this way. If language objects are people,
> then C++ objects are basically puppets. You don't tell them to do
> something; you just pull the string, and they do it. Objective-C
> objects are more independent. You TELL them that you'd like
> something done, and they'll do it if they can.
> --
>
That's interesting, because I remember a point long ago when I was
first learning OO programming (in C++), that I understood the concept
of "message passing", but that C++ didn't really implement that (nor
does Java): you're invoking a method, not passing a message. I was
always puzzled by the definition because the languages I used didn't
really seem to behave as described. It's nice to finally meet a
language that does what I intuitively understood "message passing" to
be.
Rob






Cocoa mail archive

