• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Classes and the Production of Objects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >Re: Classes and the Production of Objects (From: terry <email@hidden>)

  • Prev by Date: Re: Super vs. self (newbie question)
  • Next by Date: Re: FTPClient Beta Released - Please test
  • Previous by thread: Re: Classes and the Production of Objects
  • Next by thread: Re: Classes and the Production of Objects
  • Index(es):
    • Date
    • Thread