Re: beginning Obj-C [LONG]
Re: beginning Obj-C [LONG]
- Subject: Re: beginning Obj-C [LONG]
- From: "David W. Halliday" <email@hidden>
- Date: Thu, 07 Aug 2003 14:44:56 -0500
David Thorp,
You wrote:
...
All that said... I will be very grateful to any of you who are inclined
to read through all this and help me in getting over a couple of early
humps I've hit in understanding Objective-C.
History:
As most of you probably know by now I'm on the learning path from
having done a Pascal and "good programming techniques" course at
university 10 years ago, then spent 10 years programming in FileMaker,
to now deciding to learn Cocoa and do some "real" :-) Mac programming.
Unfortunately, I have yet to see a "good programming techniques"
course that uses a procedural programming language (like Pascal, Modula,
or C) that does anything close to a good job of preparing a programmer
for the very different world of Object Oriented (OO) programming (or,
for that matter, list processing [ala Lisp], functional programming, or
declarative programming)---the way of thinking (world view, or paradigm)
is too different.
Of course, this is not to say that the course has not given you some
good pointers and practices that will be applicable (especially for a
hybrid language like Objective-C, or C++). However, you should be aware
that you have almost certainly incorporated certain concepts of "what
programming /is/" that may not serve you so well in trying to wrap your
mind around the OO /way/.
As recommended by some of you, I've been learning C ...
Yes, the translation from one procedural language to another is not
too difficult (though the first time you move from one language to
another is always the most difficult). Furthermore, the "good
programming techniques" you learned are almost completely transferable here.
... (and have pretty
much got my head around that now I think, and on the way to Cocoa, I'm
now going through Apple's document on Objective-C. (It's on their
website <developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC>
but I've downloaded and printed out the pdf (ObjC.pdf)).
This is certainly one of the fist things I would have recommended
you to read, along with an old Byte magazine article on SmallTalk, if
you can find it (I don't remember the date: Sometime in the 80's, I
believe [I haven't read the Sept. 2002 article looking back at
SmallTalk, so I don't know how well it does at introducing the language]).
Current problem:
So right now, I believe I've pretty much fully understood up to the end
of chapter 2 ("Object-Oriented Programming") of that ObjC.pdf file, but
am struggling in Chapter 3 ("The Objective-C Language"). Here's what I
think I've figured out so far...
...
A particular kind of type that is very useful of course is a struct - i
see that as a programmer-definable type - would that be accurate?
Now... objects/classes. Conceptually, I'm currently thinking of an
object as like a glorified struct (programmer-definable type). A
struct has to be defined, but after that it's like any other type - we
declare the variables and then initialize them (as outlined above).
You are making a very common "mistake" in looking at objects and
classes in terms of "structs" (unfortunately, a view that C++ encourages).
While it is true that structures are used behind the scenes in
implementing objects (in much the same way that they are used to
implement lists in Lisp), and, while I've usually noticed that
procedural programmers tend to gravitate to this way of thinking, I've
noticed that such attempts actually tend to get in the way of grokking
the OO paradigm. (The problem is that getting one's mind around a
completely new way of looking at things tends to require unlearning a
number of formerly cherished concepts. Therefore, the longer one
persists in carrying around these former ways of thinking the longer the
"paradigm shift" is delayed, and, generally, the more painful the
transition, when, and if, it ever happens.)
Basically, I have noticed that the transition to a new way of
thinking is often helped by presenting the new concepts in a way that is
as far removed from the "old" ways as possible. (Unfortunately, this is
not helped when an OO language is created as an extension to a language
based upon a different paradigm---Like Objective-C extending C, or CLOS
extending Lisp---even though such an approach is, ultimately, helpful in
interfacing such a system with legacy code and systems.)
This is why, I believe, people with no prior programming experience
have an easier time grokking the OO /way/, and why, I believe, learning
a language that is fully immersed in the new /way/ tends to facilitate
the "paradigm shift" in someone who is trying to learn it.
Like a sruct, an object is essentally a set of variables (data
structure) and then some. (I realise that unlike a struct an object
has a set of methods to tell the data what to do. And the data
structure is hidden from outside of the object - instead accessed only
through the methods. All combined, it makes up an object. - I
appreciate there's a lot more to it than that, but go with me for a
second if that's ok). Is this all pretty much right so far?
These are, basically, implementation details. However, you do have
it basically correct (and, yes, I realize that the Apple documents
/does/ present some of these details in it's presentation).
Now, I lost it right on page 56 I think (second page of chapter 3) with
"id". Although perhaps I am just grasping it. I'm beginning to think
the idea of:
id anObject;
might be like saying
variable age;
Admittedly, I think it would be more helpful if it were
Object anObject;
(or, even,
Object * anObject;)
but, alas, Object is already a defined type in Objective-C, and such a
declaration wouldn't have the desired affect (the non-restrictive "id"
type was added to the language more recently).
...
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.
This form of explanation /does/ play into your attempt at fitting OO
within your procedural framework. (However, as I stated above, this
usually gets in the way of making the mental transition to the OO way of
thinking.)
...
The rest, I believe, others have adequately addressed.
Thanks again in advance.
David.
Like I, basically, said above, I recommend taking a detour into the
premier Object Oriented programming language, SmallTalk, in order to
better help your transition to this new way of thinking. Unfortunately,
I realize this will seem to be a needless waste of time. Furthermore,
even though Objective-C's Object Oriented nature is based upon
SmallTalk, there are things that can be done within SmallTalk that don't
translate well to Objective-C [though there is work being done by
various parties toward overcoming such].)
Just my $0.02.
David Halliday
_______________________________________________
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.