Re: Confusion
Re: Confusion
- Subject: Re: Confusion
- From: Charles Bennett <email@hidden>
- Date: Sun, 24 Jun 2001 15:21:12 -0400
Oh hell. Let me take a run at it.
email@hidden wrote:
>
>
Thanks to all who responded to my questions concerning the "*" and how
>
it is being used. However, I am now more confused than ever! Indeed, I
>
am so hamstrung by what appears to me to be contradictions in the
>
various answers, AND conflicting information in the alleged
>
documentation that I feel like I've taken one step forward and
>
five-or-six back. My level of befuddlement is so high that I can't for
>
the life of me even compose another question that might help clarify the
>
concepts I must be missing. For example, in the C textbook I have, "The
>
Art and Science of C" by Eric Roberts, the discussion on pointers begins
>
on page 454, where he states:
>
>
"In C, pointers serve several purposes, of which the following are the
>
more important:
>
>
Pointers allow you to refer to a large data structure in a
>
compact way. "
>
>
He then goes on to expand on this and offers three more "important"
>
reasons for pointers in C. For now I'm just trying to grasp this first
>
purpose and my problem is this: It was my understanding that one of the
>
prime raisons d'etre of Cocoa, and OOP in general, was to encapsulate
>
the bloody data in an object so that you didn't have to deal with this
>
pointer stuff. Why do I need an address "shorthand" for a large data
>
structure when I already have a better "shorthand" in the form of an
>
object that contains the data? Perhaps part of the problem is that the
>
word "pointer" is being used to describe too many things that happen to
>
be loosely related. Someone said that everything is a pointer, or
>
rather every object. Unless the definition of pointer is extremely
>
loose, this makes no sense to me at all. It tells me nothing! Indeed,
>
it smacks of tautology.
>
>
If I declare:
>
>
NSString *myName;
>
>
I am stating that myName is of type NSString. So, in a loose sense
>
myName is pointing to NSString. But the important thing here, IF I
>
understand this, is that I'm statically typing myName to NSString to
>
give the compiler a heads up so that it can perhaps find an error that
>
might have been missed if I just declared myName thus:
>
>
id myName;
>
>
If I have this right, then it seems to me that calling myName a
>
"pointer" only dilutes the definition of "pointer" when the word is
>
being used to describe something that is much more TO THE POINT.
IT really is a pointer but it is much better to call myName an Object and not get hung up on the fact that it is really
a pointer.
Someday there will be a reason that you are happy it's a pointer
but for now think of id simply as a variable that can hold anything that inherits from
Object (or NSObject) Yes id is a pointer (actually a pointer to
the instance variables) and you CAN treat it that way, but in practice you
let the objective c runtime messaging deal with this "pointer" more abstractly
as an Object. The cool thing about ObjC (or the worst thing depending on where
you stand on early or late binding) is that you have this common ancestor called Object
so you "know" that no matter what object you assign to myName there are some messages that it
will respond to. Yes you can completely blow it by sending a message to an object that
it can't respond to. Unless you make other arrangements the program will simply
halt. The difference is that with ObjC it's possible to get to that point during
runtime, while it's somewhat harder in C++. This is either very good or very bad
depending on how much you want to compiler to do for you.
Remember that ObjC is just a super set of 'C' It's not a full up Object Oriented Language
ala SmallTalk.
It only adds a couple of directives so "behind the curtain" it HAS to be pointers, but you don't HAVE to think of them
that way. Read chapter 2 of "Object-Oriented Programming and the Objective C Language" found at the Apple developer
site.
The whole purpose of "id" is to allow dynamic typing. The "cost" of doing
this to give up compile time checking (Like your NSString vs id example).
It's very much in the 'c' mind set that the price of power is responsibility.
'id' is indeed a pointer in the C pointer sense. It (sorta) works the same way as declaring something (void*) in a
normal C program, which in effect tells the compiler to shutup
and stop whining about the fact that it can't check your work.
>
I fully understand the need for a pointer in straight C to "refer to a
>
large data structure in a compact way," but I just don't get this need
>
in Objective-C when the data is within an object. I thought the idea
>
was to ask the object to do something with its data and return an
>
answer.
That is the idea, and what you normally do. You are getting hung up on HOW
it is done (which is interesting, but not necessary to know). id does point
to a "large data structure in a compact way". You however, don't have to care
since the runtime messaging system will deal with this "pointer to adata structure"
as an Object.
You most always do ask the object to do something with it's data and return an
answer. The point here is that you CAN cheat if you know the underlying implementation
details but you usually have no reason to cheat.
>
No doubt I'm missing something here, but once again the cryptic
>
nature of programming documentation that seems to be de rigueur is
>
driving me nuts. That and the fact that most of these _teachers_
>
writing these expensive books I have don't seem capable of teaching
>
compulsive gamblers how to lose money. Memory is now cheaper than dirt,
>
so why are we still clinging to the overly cryptic, abbreviated, and
>
acronym-riddled constructs of the past?
There are lots of languages to choose from that have dropped all of the old baggage
of the "past". ObjC is not one of them :-)
ObjC is just one step above Plain ol' C which is
just barely one step above a good Macro Assembler.
>
I'm just trying to control a
>
STUPID machine; it should not be this hard to do so!
It's not hard, it's powerful ;-)
Paraphrase of a Buddhist Parable;
A couple of priests, that are forbidden contact with women, come to a river
where a women is waiting for some assistance is crossing. The older priest
picks her up, carries her across, and puts her down on the other side. After walking
and thinking about this for several miles, the young priest can't resist in asking why the older priest had carried the
women across.
He answered, "I put her down miles ago. Why are you still carrying her?"
I suggest that you stop carrying "pointers" and use objects.
You can ask NSString to make a NSString object for you and put it in a variable
of type id or type NSString. You choose id when you might want to assign
the variable to other types of objects later, and NSString if you know
that's what it's always going to be, and you want the compiler to catch you
if you screw up and try to assign it to something else.
You can send this object messages and get answers back.
It's that simple and 99% of the time that's all you NEED to know.
chuck
"Who can't stop carrying the fact that NSDistributedObjects don't work
in daemons at startup"
>
Brian E. Howard
>
Cocoa Cult Central
>
back to square minus six!
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
--
"I have great motivational skills. Everyone's always saying how much harder they have to work when I'm around!"
-Homer S