Re: Classes and the Production of Objects
Re: Classes and the Production of Objects
- Subject: Re: Classes and the Production of Objects
- From: Chris Hanson <email@hidden>
- Date: Sat, 10 Aug 2002 17:40:24 -0500
At 12:42 PM -0600 8/10/02, terry wrote:
Would you care to elaborate on the "wrong" things that C++ teaches?
I'm curious...
The fundamental flaw with much of C++ instruction, and much of the
common use of C++, is that it takes far, far too low-level a view of
the world.
For instance, you're taught in C++ to "call member functions" and
"set member variables" and so on. You're not taught the proper names
within object-oriented programming (instance methods, instance
variables) nor the proper abstractions (send a message to an object,
which will cause the object to invoke a method) -- even though these
abstractions can be used in C++!
In other words, a C++ text will tell you
foo->doSomething();
is "calling foo's memeber function doSomething". If it were actually
teaching object-oriented programming, it would say it's "sending
doSomething to foo, which will cause foo to invoke its doSomething
method." The distinction is subtle but important. In a language
where messages are statically bound to methods like C++, it might not
make a difference, but in a true object-oriented language with
dynamic binding there might not actually be a doSomething method to
invoke; foo might actually be a proxy object forwarding messages over
the network, or it might parse the text of the message selector to
figure out what to do, or something else equally flexible.
Similarly, if you look at the C++ Standard Template Library, it's
full of this kind of low-level thinking. There is no hierarchy of
collection classes, and collection classes are not always direct
substitutes for each other. For instance, std::list<T> and
std::vector<T> both represent ordered sequences, but they don't
descend from a std::ordered_sequence<T> class that would let you pass
either of them into a function without making that function also use
a template. And they don't implement the same interface, either, so
even if you do use a template depending on what your function is
trying to do you may not be able to pass instances of either
std::list<T> or std::vector<T> into it!
And don't get me started on the pitiful extent of C++ RTTI. You
can't even look up a method given a string containing its name in C++.
So, fundamentally, C++ takes too low-level a view of the world and
C++ instruction reinforces this. Even though in most cases the
instruction doesn't have to, and by taking a slightly higher-level
message-oriented view of the world learners would have more mental
tools with which to understand dynamic languages when they first
encounter them.
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.
A class is just an instance of the class "Class". (Or at least it
looks like it, there may be Objective-C runtime details that prevent
this from being 100% of the case. But you don't have to worry about
that.)
An aside, which you don't have to concern yourself with: In
Smalltalk, Common Lisp, and Dylan, a class is an instance of a
subclass of Class called a "metaclass." In these languages you can
actually perform operations on metaclasses themselves to do pretty
powerful things. For instance, one Common Lisp project I've heard of
had a very large object database that needed to have some things
changed in its data organization. By writing code to manipulate the
metaclasses of the objects in the database, the classes of all of the
objects in the database were upgraded "in place" and the objects
themselves were all massaged to be appropriate to the new versions of
their classes.
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.
Except you can do more with class objects than just create instances.
Though as a beginner you probably don't need to know too much more
than that.
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.
Right. This is why people like Ondra and myself say that C++ is
flawed, and (more importantly) the way C++ is taught is also flawed.
(I personally believe that if C++ was taught using proper
object-oriented terminology, not only would Smalltalk and Objective-C
be much easier to learn for C++ programmers, but that C++ programmers
would write better code because they'd be used to thinking just
slightly more abstractly than they tend to now.)
The Objective-C way of doing things is actually a very close match
for the abstract concepts of object-oriented programming;
object-oriented programming is defined as "programming by sending
messages to objects" and the term was created by Alan Kay to describe
Smalltalk, a language he (and his team at Xerox PARC) invented. It's
C++ that doesn't exactly match these abstract concepts even though it
calls itself object-oriented.
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.
I don't think it was wasted at all. Sometimes it takes seeing
several different restatements and different points of view to really
understand a concept. I know that from first-hand experience with
calculus many years ago -- I muddled through until I actually saw its
use in physics, whereby my understanding fell into place (even though
I sometimes still forgot formulae).
So if between your point of view and Ondra's and mine and other
posters, the original poster finds a few things that "click", then I
think we'll have all done something worthwhile.
-- Chris
--
Chris Hanson | Email: email@hidden
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
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.