There are two major varieties of Cocoa available. The first variety, possibly the more well known of the two, is the kind that you can use to make a nice warm cup of chocolate milk. While tasty, it's hardly proper subject matter for an operating systems information site. The second variety is far more on-topic: a programming environment for Apple Mac OS X that is the modern evolution of of the original NeXTSTEP frameworks. That's what I'm here to talk about today.

I hope Apple or atleast the GCC dudes will drop this horrible "[obj method]" syntax - it makes a a source - especially when you mix it with arrays - unreadble. The 'dot' is the way to go - just like Java: obj.method.
Maybe its the reason for the missing code completion in PB.

It is much more complicated to have code completion when you have a dynamically typed language like Objective C. But code completion is much less useful in such a language, where there aren't twenty variants of the same method, each differing for the arguments type.

Regarding message syntax, I find the Smalltalk syntax (which is the syntax ObjC uses for message) much clearer than the Java one, especially when you have many arguments.

I noticed alot of compersions to C++. It may be helpfull to point out the fact that C++ follows the simula 67 style of OO not that of smalltalk. Here is a link to a nice table comparing Objective-C, smalltalk-80, C++, and Eiffel:
http://www.dekorte.com/Objective-C/Comparisons.html

This is helpful; I've been trying to get into Cocoa (I'm quite acuanted with C/C++, perl, Basic (Of course), RealBASIC, and a bit of Java). I've hate C++, liked Basic but was fruturated with gotos and its limitations. RealBASIC was good but I was quickly limited with that, and java I could never wrap my brain around.

This was very helpful; even more helpful were the links. Using Cocoadev's tutorials I'm already understanding Obj-C, and liking it. Thanks! =)

I hope Apple or atleast the GCC dudes will drop this horrible "[obj method]" syntax - it makes a a source - especially when you mix it with arrays - unreadble. The 'dot' is the way to go - just like Java: obj.method.
Maybe its the reason for the missing code completion in PB.

Used to be of this mind. Less certain now. I'm still not too keen on naming every argument. I used to have a big problem with lisp's syntax too, and I'm over it. (Waaaaay over it.)

I don't see why this would limit code completion in PB. If you have the pointer type of an obj you should be able to present reasonable code completion. (You could even detect for a Class/Interface test in a surrounding if statement and do some intelligent code completion.)

I'm hoping that code completion will make it into PB at WWDC. I really think that this feature would turbocharge application development. (I'm an emacs-with-viper-enabled kind of guy, but, having used Eclipse for the past six months has turned me around a bit.) The easier Apple makes it for newbies and middlin'-bies to wade in, the better.

I actually started doing OO programming in Smalltalk which has a format simlar to objective-c (minus the [] messaging brackets). And when I switched to Java I really though its object.method() syntax was incredible ackward, expecially when it came to multiple parameters.

So I guess what I am saying here is give it a chance after all the C++/Java syntax grew on me.

The Objective-C syntax is much better than C++ or Java syntax. I much preffer to write (and read) [myWindow nextEventMatchingMask:myMask untilDate:myDate inMode:myMode dequeue:YES] than myWindow.nextEventMatchingMask(myMask, myDate, myMode, YES). Patrick g, Ask the smalltalk comunity if they think the keyword syntax (adopted by Smalltalk and Objective-C) is unreadable.

Cocoa is by far the best application framework I've seen. And I love the fact that it can be used from so many scripting languages (see http://www.fscript.org/links.htm for a list).

This is due to the fact in C/C++, and perl, I've become used to using brackets and parens for all of my groupings; this continues with this time-honored tradition, and it makes it easier to read when a obj-method begins and where one ends (Hint: follow the []s).

GNUstep's mission page clearly states "GNUstep's goal is to create a free, superior development environment based on and inspired by the OpenStep standard developed by NeXT Computer Inc. (now Apple Computer Inc.) and the OPENSTEP implementation of this standard."

So, while GNUstep may not be a 100% clone of Cocoa as it stands today, it is (for all intents and purposes) a clone of the original OpenStep specification. The GNUstep project is adding some new classes to maintain compatibility with Cocoa, but there's isn't a 1:1 compatibility ratio. I realize that. On the other hand, while the GNUstep developers are certainly doing a fantastic job, that doesn't mean we shouldn't recognize the fact that GNUstep is basically just a copy of an original specification created by another organization.

From what I've read, you can make a null pointer reference in Objective-C. It won't kill your program. However, I've never been able to find out what the result is. Also do you have to give an object a type in Objective-C? Otherwise, how does the compiler know if you're calling the correct method on an object? Why can't you create an object on the stack? I'd have to agree with the camp that doesn't like the square braces. That combined with naming arguments (although that's not required) and Objective-C's memory model makes a statement the equivalent of (Java vector add method):

I know it's easy to get entrenched in coding in a very particular style, but the claim that having to use Objective-C's square brakets is awkward or that Java's syntax is confusing is just lame. Sorry but I guess that's a bit of a flame...

Jason,
1) Message sends to null pointers are just ignored.
2) The compiler doesn't need to know - the runtime figures it out.
3) Its just simpler that way. Objective-C objects are not meant to be thought of like C structs.
4) If you have a method with a lot of arguments, named parameters make things a lot easier, because there is no chance you are going to mix up the order. Its amazing how upset everyone gets over the weirdness of the square brackets initially. I did too, but you get to love them after a day or so, trust me!

Messages to nil (or the Nil class) normally return nil (some runtimes allow this behavior to be easily modifed. This allows you set up a big chain of messages and only worry if the final result is nil:

You don't have to deal with types in ObjC the same way you're think of. Every object *does* have a type/class it belongs to, but you need not worry yourself over the particulars to perform an operation. If you have a collection that responds to -addObject:, that is enough; why sweat over it being an array, set, linked list, whatever?

In some runtimes it *is* possible to create objects on the stack. That is not part of common systems, so clearly there is little benefit to it in the real world.

As far as syntax issues go, some of you people simply need more exposure. A professional programmer should be able to get beyond syntax issues relatively easily, and ObjC has the most minor of syntax differences from C. For your example, the equivalent Cocoa code would be:

[v addObject: [NSNumber numberWithInt: 1]];

Hardly a difficult read. Where the ObjC syntax really shines is with multiple arguments. Compare:

>1) Message sends to null pointers are just ignored.
How then do you figure out if you've made such a programming error? I've seen such things happen in C++ in UNIX, but the consequences aren't good and very hard to track down.

>2) The compiler doesn't need to know - the runtime figures >it out.
What happens then if I manage to call a method on an object that doesn't support it?

>3) Its just simpler that way. Objective-C objects are not >meant to be thought of like C structs.
Simpler for whom? Memory management is the number one cause of bugs in software. If you can't put some objects on the stack, that's more memory to manage (and thus more potential bugs). To be honest, I don't know a whole hell of a lot about autoreleasepools or whatever they're called, so that might solve some of this problem.

>4) If you have a method with a lot of arguments, named >parameters make things a lot easier, because there is no >chance you are going to mix up the order. Its amazing how >upset everyone gets over the weirdness of the square >brackets initially. I did too, but you get to love them >after a day or so, trust me!
>
>your example would be something like
>
>[v addExample:[Integer new:1]];
>
>I don't see how that is any harder to read.
Well, I remembered the object initialization process for Objective-C requiring two methods, but I guess I'm wrong. As far as naming parameters being easier, not only do you have to remember their order, you also have to remember their name, unless you have a reference for the class you're using, and then the point is moot.

As far as naming parameters being easier, not only do you have to remember their order, you also have to remember their name, unless you have a reference for the class you're using, and then the point is moot.

That is true, however, [foo containsObject: bar]; is easier to read and (well, not necessarily in this example) understand.

GNUstep and Cocoa both are OPENSTEP implementations, plus, both bring along extensions to that specification.

GNUstep does indeed implement some of Cocoa's extensions as well, but the primary focus is a direct OPENSTEP implementation. If it was to go after Cocoa, rest assured that Apple Legal will take a very close look at it...

So, bottom line is, you will be able to write applications using GNUstep and then port over to Cocoa - eg. as Ludovic Marcotte did with GNUMail ( http://www.collaboration-world.com/gnumail/ ) - but the other way round will be much harder to do.

To be precise, Cocoa is *not* an implementation of OpenStep. Cocoa is highly similar to, and is based on the OpenStep API, but not every OpenStep class or method is present in Cocoa, and there's a great deal of Cocoa that was never in OpenStep.

OK, I see what you all are saying. GNUstep is based on OpenStep, as is Cocoa, but both add on to that original spec in different ways, therefore, GNUstep is not a "clone" of Cocoa, but rather OpenStep. OK, that sounds logical. Since I'm not familiar with exactly what Cocoa has added to OpenStep, I didn't realize the extent of the differences.

While the true goal of GNUstep is to be an OpenStep implementation, it's also right to say that quasi all the additional classes from Cocoa are implemented (with the minus of NSDrawer and NSToolbar -- and yet some people seems to works a bit on them). In fact, the major problem when porting cocoa->gnustep is eventually the lack of ObjC++ (and of course of the proprietary frameworks also available on Mac (quicktime...) that could be used by an application). So imho, people should be aware of the different goals and possible differences, yes, but overall both platforms are quite compatible.

I've been looking to the GNUStep framework. I've done only a bit of C/C++ so it's a bit harder for me. I hate having to write a bunch of code and weird macros Just to create a window with a few buttons (aka wxWindows/C++). Using Gorm I created a very simple "hello world" app and wrote very little code. Not only that, my app came with a menu bar and a working exit menu item! And if I drag the menu someplace, it shows up in the same place when I run it again! I didn't write a single line of code to do such things! I like C++ and all, but I don't want to get into wierd things such as virtual methods and such. When python bindings for GNUStep show up I'll definately jump in. I can't wait till part 2!

Openstep and Cocoa differ in that Cocoa is a superset of Openstep.
Cocoa has XML property lists (Openstep specifies textual, and I prefer it this way, or this behavior should be able to be toggled), some Web-enhanced methods, and some revised UI classes.

If i recall, the creators of smalltalk orginaly envisaged a language which would be used to teach children how to program computers.
Hence the syntax was designed to be as logical and easy to read as possible, where C etc and C++ were designed by techies and committes looking for the quickest easiest way to achieve a particular task (hence all those stange little syntaxical anomilies which are so much fun to play with when you first learning the bloody things ....)

Well personnally I found the [] syntax quite elegant since the beginning ... as it "feels" more like you send a message and not simply do a method call. And it let you send messages quasi- in the form of sentences (with the possibility of naming the arguments).

Frankly it's so much better when you take the readibility of a program in count...

At the beginning I found also the OpenStep API quite "verbose", with long names, etc. But in fact it's not painful tu use (I adapted very quickly), perhaps because it's easy to retain the method's names ... And the big, big advantage, is here again the readibility of the code. That's one of the big plus with ObjC/OpenStep programs ...

(to the one asking for a comparison between Qt and OpenStep, in my opinion, OpenStep is better. More coherent. But Qt is a also a wonderful toolkit -- that's what I used before committing to GNUstep and Objective-C ;-) futhermore, the Signal/Slot Qt thing is similar to Objective-C . Only that with Objective-C, it the normal method ;-)

"As far as naming parameters being easier, not only do you have to remember their order, you also have to remember their name, unless you have a reference for the class you're using, and then the point is moot."

Cocoa methods are named very consistently -- you can often just guess at the method name you want to use w/o consulting the documentation.

The main benefit with named arguments is not in recalling method names, but in reading source code. If you are not familiar with a piece of code (or you are revisiting your own code after a long hiatus), a line like

[shape drawAtXCoord:2 yCoord:7 width:5 height:10 bordered:YES];

is a lot easier to decipher than the more Java-like

shape.draw(2,7,5,10,true);

I wish more languages provided named arguments. The only ones I know of are Smalltalk and Objective-C. Any others out there?

Thanks for the article. Now I can truly understand why (with respect to ObjC and Cocoa) C++ is more commonly used than ObjectiveC. At first glance, GTK+ and KDE libs are much more simple than cocoa. More clearly defined functions and less code. Also, C/C++ is much more optimised than ObjC.

Well, you can use comments to document code in other languages, which makes the point of named arguments rather moot.

Sure, a lot of people don't bother commenting, and you may argue that its more of a hassle to do than named arguments, however I find it a good practice, as it will also make your code easily readable, in any language.

As a long time Smalltalk (20+ years) and NeXT/OpenStep (12+ years) user/developer, who currently uses BOTH systems, I find that they each have their advantages and attractions. Certainly Smalltalk code is easier to read and just as certainly the OpenStep GUI is amazing (Win95 was cloned/devolved from it).

Objective-C is an excellent language with it's well known merging of C and a variant of Smalltalk syntax, however since it lacks true automatic memory management I find my programming style must change significantly to take this into account. While programming in Smalltalk one can simply forget about memory issue, for the most part. This definitly affects style, effort, complexity and other factors in developing software.

The real pleasure of Objective-C on the OpenStep platform is the library of objects in the Application Kit Framework. These are simply designed very well and pack a mean punch. The compact size and potent density of the frameworks are comprehensible to most programmers thus they are very usable. One can write very powerful applications with it, as evidenced by the many awesome NeXT/OpenStep/Coca applications that have been written.

Any language with full automatic memory management has it's advantages over those without. In this regards Java joins Smalltalk, Lisp and others in being "better" than C, C++ and Objective-C.

Languages that make the name of "parameters" in a method part of the method name seem to make the programs much easier to read. This is especially important for large teams. Smalltalk and Objective-C programs are amoung the easiest to read as they have "literate programming" principles built in.

It's also important to have access to the source code or documentation via "browsing" tools while reading the source code of large and unfamilar systems. This is even more important for langauges like C++, C, Java, etc.. where the function names are not so readable

The differences in the lanuages and their supporting libraries make a difference, including a significant difference, in the outcome and the path taken to get there.

I for one, prefer languages like Smalltalk, where the syntax is as easy to write as it is to read. While I can program in lanaguages like Java, C++, Perl, Python, Objective-C, C, Assembly Language, etc, they are much harder due to their "syntax".

It really depends on what you are trying to accomplish. The technicial success of the Objective-C based OpenStep/Coca applications and systems shows how even a few of the principles of Smalltalk can have a huge impact upon the outcome.

The libraries of objects in the many dialects of Smalltalk have variation and have evolved to meet the needs of the various their target markets. Smalltalk and it's libary of objects, while powerful, aren't perfect, which tool is?

The GNUStep effort offers a complelling opportunity with the merging of Smalltalk within the OpenStep standard. Good looks with a good language. It's worth tracking, using and contributing to.

There are features of languages that can make significant differences in readablity, ease of use, performance, cost, maintainablity and overall results. I'm most interested in and my choices motivated by the features of languages that take over some of the burden from programmers (and shift it to the machine leading to a reduction in cost of development and overall development time). This is the purpose of progress after all, isn't it?

There are tradeoffs with each language feature. For example, automatic memory management makes a huge difference in productivity with a tiny cost in run time performance.

Un-typed data/objects, as in Smalltalk, make a huge improvement in productivity. Some "every data item must be typed" aderants are concerned about run-time bugs. In practice, bugs occuring in untyped systems have more to do with the "architecture" and "design" than with the "untyped" characteristic. There are some situations where having types is important and it may well be that a typed language is better suited to the task.

Regardless of which language you use it's obvious that architecture and design of the supporting object, data and code libraries playes a significant difference.

The success of the architecture and design of OpenStep reveals this. While Smalltalk is a better language and it's core object library beats OpenStep's/Coca's hands down, OpenStep has an excellent feather weight Application Framework that goes a long way towards success. NeXT put their design attention on what people SEE after all!

The bottom line is computer languages are tools and tool selection for any particular job is an important aspect in many, but not all, projects. There is more than one road to Rome, after all. The tower of babel is the reality in the landscape of computer languages. Interoperation systems such as XML are paving a way for systems created in most, if not all, languages to be able to communicate. At last applications and systems developers are freed from many of the constraints placed upon them by others who prefer different choices. Overall architecture and design influence systems as much as - if not more than - which language you happen to choose to utter the prgram in.

May you choose your tools well for the task at hand, which by the way includes the choice of language for building operating systems. The language of choice for the operating systems project that I'm working on is a language that is evolving from Smalltalk and Assembly languages and advanced application frameworks such as OpenStep. There are enough cpu cycles now to raise the importance of architecture and design above that of simple raw performance. The computer age has just begun and the future is wide open for the systems of your dreams.

Which is exactly the point. It's better to force someone to make more readable code than to let them not. Remember: A True Klingon Warrier Doesn't Comment his Code. Or whatever the quote is.

This is crazy talk. I almost always prefer when languages stay away from hard and fast rules. An example of the difference between python and java. In java there are rules that aren't there for technical reasons, but just to keep you in line. Whereas in python they allow you to break typical object oriented rules if you please. This allows you do take a "shortcut" if you want or need to.

It is like in certain classes where I program C professors will say "No global variables." Not that a global variable causes problems, but they see it as a shortcut because it breaks certain programming models. I see it as the most efficient way to get the job done at times.

I have a long programming history. I started programming in the early eighties (I was 14 then) with line-numbered Basic on a Commodore PET, followed by Pascal and C/C++ during University.
At work I have used Cobol, Visual Basic and for the last two years JAVA. I am a Mac owner for 1.5 years now so I came in contact with Objective-C and I agree to Jay's post:

Once you got passed the initial learning curve, Objective-C & Cocoa is incredibly elegant and intuitive.

It is like in certain classes where I program C professors will say "No global variables." Not that a global variable causes problems, but they see it as a shortcut because it breaks certain programming models. I see it as the most efficient way to get the job done at times.If you'd ever worked on a large project with a programmer who held that opinion.. well you'd know its simply not true. I'd like tutors to be able to give people a smack around the ear if they spot a global variable.

Sorry, but I do find the [] syntax confusing, as it's never clear what is the method and what are the arguments.

To claim that named arguments are easier to read may have some merit, but I'd note that most scripting languages let you do this (python does) and in languages like Java/C++/Delphi it's less important anyway because in a good IDE you can hover the mouse over a method call to see the prototype anyway.

I've not seen anybody mentioned the big disadvantage of Objective-C, in that it's very slow. There's a reason languages like C, C++, Delphi etc work the way they do, and that's because static typing:

a) Lets you catch some errors you otherwise would miss and
b) is very fast.

To be honest, I don't see what advantages ObjC has over Python except perhaps the ability to use C code more easily. They both support OO, late binding, but Python has the advantages of a non-confusing syntax and true garbage collection.

As with Python, they are particularly useful when you have default values.

In OCaml, there is the additional benefit that you can perform a partial application specifying parameters other than the first one. A brief explanation - given an f : 'a -> 'b -> 'c, you can only do f x to get a function 'b -> 'c, but with f : x:'a -> y:'b -> 'c you can say f ~y:y to get a function x:'a -> 'c . Obviously, you could always use (fun y -> f x y) but the shorthand is convenient. In simpler terms, if you apply a function without giving all the arguments, the result is a function taking the remaining arguments. Without named arguments you can only give arguments in order.

Sorry, but I do find the [] syntax confusing, as it's never clear what is the method and what are the arguments.

Well in the beginning I had difficulties too, I didn't "got it". In fact, it's really simple :

[myObject messageWithArgument1: foo andArgument2: bar];

the function's name (function signature, or selector) is NOT

messageWithArgument1:

as you could think, but :

messageWithArgument1:andArgument2: !

In fact, you put your arguments "inside" the method's name/call ... it's not simply that you "name" the argument, the "argument's name" is part of the method's name.

I've not seen anybody mentioned the big disadvantage of Objective-C, in that it's very slow.

It's not "very slow". It's a compiled language, and frankly I don't see the difference when programming with GNUstep or with Qt. I "know" that methods invocations are a bit slower due to indirection, but it's barely noticeable. I think that today's computer are too fast ;-) (and remember, NeXT ran on 68030, and their eventual slowness was mostly due to DisplayPostscript, not ObjC). Anyway, the biggest problem due to rapidity in a program is generally due to a bad algorithm/architecture rather than the language itself.

And of course, if you want, it's trivial to "cache" the method call, thus no more indirection, it's as fast a standard C function call !

You could easily use directly C if you care so much (never had the need to do that in fact).

Python has the advantages of a non-confusing syntax and true garbage collection.

Personnally I can't stand the tab thing with Python... ;-)
But what's your thing with garbage collection ? With GNUstep, you are free to use a real garbage collector instead of retain/release ! (Mac OS X can't, yes, but it's available on GNUstep).

But strangely, retain/release/autorelease is more used anyway (I think that's because it's quite simple mechanism, efficient, and far painless than C memory handling, and not very complicate).

For what it's worth, I'm writing a signal processing app for some of my robot work (it's a test suite for a c++ library to smooth out "warbly" sensor input, the warbles being spikes and pits resultant from the power source being used for multiple mechanisms, like servos, serial IO, etc etc).

So, since I'm developing on mac os x, in std c++ -- what I do is write all my code as libraries, and then I write cocoa guis and objective c++ lib wrappers so I can test the mechanisms. It sounds like a pain, but really it's not so bad. It's kind of fun, actually.

Anyway, last night, in *TWO* hours only, I was able to write an app, entirely in objective c, which generates an abitrary number of fake sensor inputs, plots them along a graph with subpixel precision (go quartz!), and maintains a fast searchable "history" of values. At the moment I haven't started writing my signal processing stuff (because I only started last night) but the point is, now I have a fully GUI noise generator of sorts which I can attach my c++ library to to test the cleaning algorithms.

Anyway, this isn't a complex piece of code, but the fact is, I wrote it in two hours only, and when running it takes up less than 5% cpu -- complete with the antialiased plotting of multiple inputs.

Frankly, if objective c is supposed to be slow, I don't believe it. It runs beautifully, and it's quite legible. I'm not going to convert, since really I'm a c++ guy, but frankly, I think I'll be writing my GUIs in onbjective c from now on. The right language for the right task, right?

There is no, one, object-oriented programming language for the masses. I'm learning C++ right now because I want to contribute to KDE. If I wanted to contribute to Gnome, i'd probably learn objective C or pure C. Use the tool that's right for the job.

Over the last three years, I've taught Cocoa to I think between two and three hundred engineers. Most have had a C/C++ background. Initially, most view the square-bracket syntax as, at best, "odd". By the end of a week, most seem either to like it, or at worst give it (albeit occasionally grudging) respect. Long-term experience shows that the "named arguments" style leads to more-readable, more-easily maintanable code. To those for whom this is the first exposure to the syntax I'd say, "Try it for a while before you rant."

Regarding other aspects of the environment:

One could perhaps summarise Objective-C as being behaviour- rather than type-oriented. Those steeped in a long C++/Java tradition typically find the idea of not knowing what "type" an object is discomfiting. Experienced Objective-C developers are quite relaxed with the idea of just sending a message to an object, and expecting that the Right Thing will happen. The wide variety of Cocoa applications running reliably on users' desktops suggests that the Objective-C developers' attitude is justified...

As for memory management, this is another area which newcomers, and especially those who haven't written a line of code yet, think will be difficult. Typically the difficulties are of their own making. The strategy implemented in Cocoa is consistent, reliable, and simple. It's a shame Mr. White didn't see fit to link to the longest-running Cocoa-oriented website, since it includes a number of articles on the subject of memory management:

Those who persist in "not getting it" are, in my experience, typically those who are least willing to "let go" of their C++/Java experience and work with, rather than against, the system. Please note, this is an observation, not a value judgment. In a similar vein, I am sympathetic to those who would like the "freedom" that garbage collection offers, however I wonder how many of those who demand it have looked in detail at the full range of reference types in Java. And have considered the effect of a full garbage sweep in a video-editing application as the user is fine-tuning sound-track placement. Most developers quickly get used to the memory management system, and grow to appreciate the additional control that it gives them over their application's resource requirements.

Finally, regarding speed. There are two aspects to this:
(a) Recall that this is an environment that originally ran more than adequately on 68040-based systems with 16MB RAM (some might also say that the 68030-based systems ran fine with 8MB RAM, but I'll stay in easily-defensible territory). The overhead of a method lookup over a function call is minimal (I think it was estimated by someone once at around 10% -- note that there's a lot of caching). If that has a significant impact on your application's performance, I'd suggest that either it doesn't do very much, or it's badly architected.
(b) The slowest-running application is one that hasn't been deployed yet. 15 years on, Cocoa still seems to be the best RAD tool in existence. And better than just a RAD tool, you can take your first attempt and develop it into an industrial-strength application. This is in part due to the flexibility Objective-C offers...

The ordering of the parameters is not arbitrary. [object method: 1 With: 2 And: 3]; will call a different method than [object method: 1 And: 2 With: 3];. The parameters have no names, it's just the name of the method that has been "spread out". If you look at the name of the selector you will see that it will be method:With:And: in the first case and method:And:With: in the second case. This would be no different than having a C++ method called methodWithAnd and have the same "ability" to tell the intent of the parameters.

Oh and mmalc, garbage collectors have proven to be at least as effective as manual memory management and often even better. With todays powerful computers there is really no reason NOT to use garbage collection.