Re: Classes and the Production of Objects
Re: Classes and the Production of Objects
- Subject: Re: Classes and the Production of Objects
- From: terry <email@hidden>
- Date: Sat, 10 Aug 2002 12:42:09 -0600
On Saturday, August 10, 2002, at 06:16 AM, Ondra Cada wrote:
On Saturday, August 10, 2002, at 09:41 , terry wrote:
I'm going to take a shot at answer this, even though my Cocoa skills
aren'
t quite up to par yet. ;) (A lot of this is similar to Java/C++)
Actually, C++ is the biggest hurdle in learning any dynamic
object-oriented language: it teaches you all the wrong things. (Java's
somewhat better, though still not perfect.)
Would you care to elaborate on the "wrong" things that C++ teaches?
I'm curious...
It certainly may not be the most elegant language, and it certainly may
not be the best OO language, but saying that it teaches all the wrong
things makes me feel like I've wasted part of my life away learning it.
"A lot of this is similar to Java/C++" is simply my opinion, and I
don't feel that I should have to append that every time I say something
that people don't agree with.
I'm trying to learn here just like everyone else, and to me, a lot of
this stuff *is* the same as in C++ and Java (on an abstract level).
Granted, messages have been somewhat difficult to learn, but that's
because they just don't exist in the languages I've used.
I want to learn. Teach me, don't berate me.
When you define a new class in a program, is an object created
immediately
and automatically from that declaration (such as at runtime) or does
the
class exist as raw code and need an instigator to make an object?
No, an object is only created when you specifically instantiate an
object.
Nope. The class is an object too. Whenever the difference is important
(like here), the object you instantiate is, surprisingly, an instance.
It is an object in the sense that it occupies memory, and can be sent
messages, and call methods. It is NOT the same as the object it
creates. I was trying to make that distinction. According to my
dictionary an object is:
6. Computer Science A discrete item that can be selected and
maneuvered, such as an onscreen graphic. In object-oriented
programming, objects include data and the procedures necessary to
operate on that data.
So yes, a class is an object, but there is an important distinction
between a class object, and a class' instantiated object. So rightly,
I shouldn't have said "No, an object is only created when you
specifically instantiate an object." but for the most part newbies are
concerned with the object a class creates, not the class object itself.
The class is a template for an object. Think of it as a blueprint.
You can have a blueprint of a house, but that doesn't mean you have a
house. It means you have instructions for a house.
Yup. And the blueprint of course is *another* object: not a house, but
an object of different kind. It's the class.
It's an object, but probably not the object that new people are worried
about, in my experience. People shouldn't need to worry about what a
class object does, other than that it creates the object that it has
the blueprints for... that's what encapsulation is all about.
I'm not sure if you *can* have class variables... can someone else
elaborate there?
Right, you can't.
I do know that class methods are specific to the class, they do not
extend to object, and object methods do not work with a class
declaration,
even though they are defined in a class declaration. :)
Ouch...
This is what I mean about not berating... If I'm incorrect in some
assumption I have about the language, please tell me that it's
incorrect, I don't appreciate the above sort of criticism... I tried
answering the question to the best of my ability, and as such I think
that deserves a little bit more respect than "Ouch...".
(a) there are class methods (+). They are used when the class receives
a message. They have nothing to do with the instance object;
(b) there are instance methods (-). They are used when an instance
receives a message. They have nothing (but for some hidden
implementation details) to do with the class object.
...NSFoo does look up the "doFoo" message in it's "selector table"
(Is that the correct terminology?)
Not quite, but the difference is negligible (AFAIK, it's called method
table ;)
In other words, classes can *not* (to my knowledge) act upon "-"
methods,
and objects can *not* (to my knowledge) act upon "+" methods.
They're separate.
Do please call those "objects" of yours instances, for that's what
they are (classes are objects too). But for this, precisely. Those
sets of methods are completely separate.
A class' job is specifically to create and deal with it's objects.
It doesn't deal with anything else. (AFAIK)
It can deal with more or less anything else, but usually does not.
Objective C seems to be *much* like Java and C++ in some respects.
Class methods exist in Java, and they behave pretty much the same
way...
Up to some limitations which soon become paramount -- like that you
can't use this (ObjC self) or super in Java's class methods. Or that
you can't include class methods in interfaces (ObjC protocols).
Certainly... but interfaces are ObjC specific, just as you can't use
C++ classes in C... they didn't exist.
The way that classes and their instantiated objects work is a very
similar thing though, if you take away all of the ObjC stuff, and
forget about things like the STL, and forget about the language
specifics semantics, and how memory is laid out and whatnot.
It's an abstract concept that doesn't need to be language specific, and
I think that's important for newbies to understand that abstract
concept, not the ObjC way of doing things.
I'm certainly not a pro at this stuff, but I'd like to feel like an
effort to help someone learn something is not wasted because I wasn't
100% correct in what I said.
- Terry
_______________________________________________
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.