Re: Obj-C, class methods and instance methods
Re: Obj-C, class methods and instance methods
- Subject: Re: Obj-C, class methods and instance methods
- From: email@hidden
- Date: Tue, 21 May 2002 11:02:14 -0700
Sanj W. wrote:
|Im trying to understand the difference between class methods and instance
|methods in Obj-C. I thought that class methods are similar to static methods
|in Java, where one could call the method without instantiating an class.
Chris Hanson wrote:
|Semantics time: You don't call methods, the runtime invokes methods
|when you send messages. This distinction is subtle but very, very
|important to understanding the gestalt of real object-oriented
|programming. (I wish people here would make it more often, it helps
|to keep things clear.)
Speaking as one of those people who consistently fail to make this distinction, I fail to do so because I see no distinction to make. "Calling" a chunk of code is simply transferring control to it, leaving a trail of breadcrumbs behind so you can find your way back. "Invoking" a chunk of code is exactly the same thing. Neither one refers to any particular implementation, and, in fact, what magic happens behind the scenes to make it all work is usually unimportant. Objective-C uses one kind of magic, C procedures use another. For most programming, the exact nature of the magic has no effect on the final result. (Even for C, the particular magic used has varied from machine to machine.) Yes, knowing how the magic works lets you do things you can't do without knowing, but those situations tend to be the exception, rather than the rule. They are not "object-oriented programming" per se, but are simply taking advantage of features of the language. (In the Ruby language, for exampl!
e, in which *everything* is an object, you can do things easily that are hard to do in Objective-C if you understand how Ruby's kind of magic works. Those things aren't more or less "object-oriented", either. They're just language features.)
Actually, worrying about the exact implementation will likely *impede* "understanding the gestalt of real object-oriented programming", because doing so focuses attention on the particular quirks and idiosyncracies of the language at hand, rather than on the concepts common to *all* languages. What matters is not knowing how Objective-C does method calls, but knowing that what chunk of code is executed by a method call depends on the class of the object involved in the call. This is true whether you use Objective-C, C++, or even Ruby. What matters is understanding the very idea of "an object"--that it is "active data", capable of modifying itself in response to outside requests--and understanding *how* you have to think to do object-oriented programming well. Object-oriented programming is not a language, or an implementation. It is a way of thinking about programming. (It's not by accident that Bruce Eckel's books are titled "Thinking in Java" and "Thinking in C++".) If you!
can think the "object-oriented" way, you'll have no trouble.
Glen Fisher
_______________________________________________
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.