Re: beginning Obj-C [LONG]
Re: beginning Obj-C [LONG]
- Subject: Re: beginning Obj-C [LONG]
- From: Chris Giordano <email@hidden>
- Date: Thu, 7 Aug 2003 09:55:20 -0400
David,
Just a few comments:
The analogy is: Is saying "id anObject;" merely declaring an object
without saying what type of object it is, simply because objective-C
allows us to change what type of object it might be during runtime? Is
that it?
Probably, but I think I'm being caught on your wording. When I read
"change what type of object it might be", I think that you're
indicating that you will have anObject pointing at some object, and the
type of that object will be changed (i.e., same object, but different
type). That doesn't happen, per se. That is, the object doesn't
change. What you can do, though, is point anObject at various
different types of objects.
Think about it this way: anObject is like a telephone number. The
phone number can be that of many different things: your mom, a friend's
cell, someone's car, a bank, an office fax machine. There are certain
fundamental characteristics of phone use that you can count on -- you
can generally communicate some kind of information from your end of the
line to the other and vice versa. However, what information and how it
is communicated is going to differ based on what's on the other end of
the phone. You're not going to have the same conversation with your
local bank that you would with your spouse, for example. And talking
to a fax machine is going to require some very flexible vocal skills
for it to be a meaningful conversation.
And of course, phone numbers change. In some cases, that can have real
world significance. Have you ever picked up the phone and had a fax
machine scream at you? Or another good real world example: the last
place I lived I had a phone number that used to be of a tax preparer.
One day I came home to a message that someone was leaving the country
for a month or so and needed us to do her taxes. If she had left her
number, we might have been able to call her to let her know that we
weren't a tax service.
To me, the key here is that anObject doesn't actually contain an
object, but merely points us to it. The object can be pretty much
anything, but the object is the object. anObject merely gives us a way
to access it.
The nice thing here is that there are plenty of ways for us to find out
what anObject points to at the moment ([anObject class], [anObject
isKindOfClass:...], [anObject respondsToSelector:...], etc.). So, you
can make sure that what you want to do with the object is something
that it is capable of handling.
I feel as if I were explaining this I would have explained first that
one can define a class (eg. "class Rectangle;"), kind of like defining
a struct - programmer-definable type, then I would have explained how
to declare an object of a certain class (eg. "Rectangle myRect;") kind
of like declaring variables of your defined struct, and then later
explained this extra cool feature of being able to declare an object
without saying what class it is if you want (eg. "id myRect;"). But
then of course is the possibility that I'm way off base and got it all
wrong.
The big distinction here is that unlike declaring a struct variable,
which allocates the space for the struct, you're not allocating the
space for your object -- you're just creating a place to tell you where
the object you finally create is. Think of it as building a house
(declaring a struct) versus buying an address book (declaring anObject
as an id). In the former case, you have the object; in the latter, you
only have something that will tell you how to get there once it's there.
From a Filemaker perspective, I can give you a very rough analogy (I
haven't done 10 years of FM work, but I've done a fair bit):
I've created relationships in Filemaker and then later changed/moved a
file in the relationship for some reason (often upgrading from one
version to another, or changing machines). Filemaker, when attempting
to access the relationship asks for the location of the file it can't
find. Here, the relationship is a bit like anObject. It is indicates
the location of the related records. In this case, there are certain
expectations of it -- somewhat similar to if we declared anObject as
id, but then treated it as if it were an NSString everywhere. I can
manipulate Filemaker somewhat to change the contents of the
relationship by changing the file involved, much like we can point
anObject at various files. Filemaker places restrictions on what the
properties of the file should be, again much like we'd need to do in
our handling of anObject -- we need to make sure it can do what we
think it can.
So the big question is, from my explanation above, have I understood
this correctly, or am I way off base?
I think generally you've got the idea, but there may be some nuances
that are a bit off base. It could be your wording or my reading of the
message. If so, then you can safely ignore this. If not, hopefully
this helps to clarify the distinction.
chris
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.