http://www.osnews.com/story/3490/Cocoa_101_Object-Oriented_Programming_for_the_Masses_-_Part_2 Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Fri, 27 Nov 2009 07:55:30 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread? http://osnews.com/thread? You don't really touch much on the Cocoa part of things. Cocoa is a framework. Objective-C is a language.
What I would have found more interesting is an exploration of the Foundation and Appkit frameworks. Wed, 07 May 2003 08:00:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? If, in your method - (void)dealloc { ... }
you fail to call [super dealloc], as in the example I can see in this article, then your instance variables will be released (and garbage collected), but not those in any superclasses, and ultimately, the object itself will not deallocate. This causes a serious memory leak. Wed, 07 May 2003 08:28:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? ...very good.

Just this.

Ralf. Wed, 07 May 2003 08:45:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? While I agree with dysprosia to an extent, perhaps the author is planning on continuing to write more articles, and Cocoa does require at least basic knowledge of Objective-C. Wed, 07 May 2003 09:21:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Very nice, and I would love to read more. Are you sure you don't want to spend some time on Part 3, Jared? Pretty pleeeaaase? :-D Wed, 07 May 2003 10:27:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? There is another (treacherous) memory error in the sample code...From the Cocoa documentation (Programming Topics - Memory Management):


It is possible for you to obtain a new object by invoking a class method of the form +className.... These class convenience methods create a new instance of the class, initialize it, and return it for you to use. Although you might think you are responsible for releasing objects created in this manner, that is not the case. Because the class method allocates the memory for the object, it is responsible for releasing that memory, thus class convenience methods should return their values autoreleased.


Thus, when you create in -init a NSCalendarDate or a NSColor through their class methods ([NCalendarDate calendarDate] & [NSColor clearColor]) you're actually getting an object that will be autoreleased in a real world application. If it doesn't fail on your tests it's because you probably don't have a running NSAutoreleasePool in place. For a correct programming, you should either:
- retain it (sensible thing to do, if you want to use it later)
- avoid a release in -dealloc (because the object will be gone anyway)

Memory management in Cocoa is wonderful when you finally manage it, but has its conventions... Wed, 07 May 2003 10:38:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Marko Riedel just started to write a GNUstep cookbook (in the same spirit as Perl cookbook), but it's useable as well as a Cocoa cookbook :-)

see http://www.roard.com/docs/cookbook/

other tutorials : http://www.roard.com/docs/

Happy stepping Wed, 07 May 2003 11:26:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? As described, it sounds like Objective-C uses reference counting and language keywords for memory management.

I'll stick with Java... (At the expense of running a background thread to handle GC)

Reference counting was a technique explored in C++ texts as a prototypical garbage collection approach. (Scott Myers, smart pointers? I could be wrong.)

It sounds like extra work for the programmer, implementing code to do reference checks everywhere. And if you miss some, potentially problems abound.

I'm not saying Java doesn't have memory issues, just that the technique in objective-C has been discredited.

Ultimately a question of pre-compile checking through development tools (obj-c) or by the runtime system (java)

See
http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc_p.html
For details of GC. (A very old article, not accounting for advancements in JVM technology over nearly 7 years!!) Wed, 07 May 2003 12:07:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? on reading my previous posting. I came off sounding as a smarmy Java person.

Nothing against Cocoa the environment, in fact Java bindings for *step such as
http://www.gnustep.it/jigs/index.html
look most interesting... Wed, 07 May 2003 12:15:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I'd hardly say that reference counting GC has become "discredited." I haven't used ObjC, but I have used the reference counting equivilent in C++. A reference counting smart pointer, like shared_ptr from Boost, is just as good as garbage collection in most cases. All you have to remember is that instead of:

int* i = new int

you do:
shared_ptr i = new int

After this, 'i' will automatically take care of deallocating memory when it goes out of scope. Wed, 07 May 2003 13:21:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? But when do we get into the chocolate theory behind cocoa?:)

And what about milk to mix ratio?:)

More seriously, it is nice to see someone writing about the great programming enviroment that Cocoa/OPENSTEP/GNUStep provide. Hopefully it will get a lot of Linux people interested in it since it would give Linux an edge over Windows in ease of programming and quality of programs, not to mention the fact that it would solve a lot of the compatibility across distros problems that can be seen today. Just think, no more package management problems and programs that have more consistant and user friendly interfaces than anything that Windows has to offer. Wed, 07 May 2003 13:25:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Well reference counting isn't very difficult to program with, simpler of course than malloc/free, and it's more efficient than garbage collecting ... it's a good solution.

Anyway you could use garbage collecting with GNUstep if you want, althrough I never used it (reference counting don't bother me and I like to have a better control on what is done). But GC isn't available with Cocoa. Wed, 07 May 2003 14:50:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? (I'm being the devil's advocate here - so forgive me...) I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform? As an enterprise developer I can tell you that there's no way any IT shop I know of would consider going back from Java or .NET. Yes, you can write Cocoa apps in Java. But again, why would I do this instead of SWT or Swing?? These facts alone will keep Apple in the consumer market - barely. Wed, 07 May 2003 15:48:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > Well reference counting ... [is] more efficient than
> garbage collecting ... it's a good solution.

This is not always true, sometimes a pure GC is more efficient. Wed, 07 May 2003 16:00:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? "(I'm being the devil's advocate here - so forgive me...) I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform?"

Cocoa is an implementation of the OpenStep specification. It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows. Wed, 07 May 2003 16:02:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? This is not always true, sometimes a pure GC is more efficient.

I agree ... sometimes it is more efficient. Wed, 07 May 2003 16:05:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? "Cocoa is an implementation of the OpenStep specification. It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows."

That's great but I just don't see developers embracing it en masse when Microsoft, Sun, and IBM are pitching a simpler development paradigm - which truly applies to 95% of application development requirements out there. Very few apps need such fine control over system resources these days because it's far less expensive to scale up than it is to write such concise applications (that's not to say that some apps wouldn't benefit from it). If you look at how companies are spending money right now, you'll note that it's on creative integration and scaling (up or out). Few, if any companies, are switching from VB, Java, or .NET to C, C++, or Objective-C. That's all I was saying. ;-) Wed, 07 May 2003 16:59:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Aaahhh! I did forget that I need to retain the calendar and color objects since they were already autoreleased. Yes, I didn't go too much into the fact that convention dictates, for the most part, that new objects returned by convenience class methods have been autoreleased. I'll make sure I fix this right away, along with the missing dealloc message that should be sent to the superclass after the instance variables have been released.

Thanks everyone for catching these mistakes!

Jared Wed, 07 May 2003 17:03:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? "It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows."

This is a real question:

Would it help if Apple started really pushing cross platform Cocoa (openstep?) programming tools for other platforms? Would it be helpfull to all *NIX environments if they all shared this common approach? Wed, 07 May 2003 17:18:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform?

I have a hard time imagining developers embracing MFC... why would anyone want to use a closed framework that is bound to a single platform?

Look, I'm all for cross-platform solutions, but using things like Swing/Qt/etc is a tradeoff. You usually can't access all of the GUI functionality of the platform, and its often obvious that your product isn't a "native" application.

What most large applications do is keep the back-end code in ANSI C/C++, then use native toolkits for each platform GUI. So in OS X, the GUI would be in ObjC + Cocoa. In Windows, it would be in MFC. The beauty of ObjC + Cocoa is in just how quickly you can create a fully-functioning GUI and integrate it with the rest of your app.

And for the posters interested in Java: Apple provides Java bindings to Cocoa. It's built into their tools, so when you write a Java app, you can forgo swing for Cocoa if you want (again, to get a real native feel for the app... or if you just prefer Java over C/ObjC). Wed, 07 May 2003 17:36:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? what is far more important than the language (considering it has some "common" features like Objects support, of course), is the quality of the development framework and perhaps the developpers tools. And honnestly, OpenStep is way ahead if you considere quality, consistency, elegance and ease of use. I don't even speak about InterfaceBuilder (or Gorm in the case of GNUstep) for creating GUI.

It's a truely wonderful framework. You develop way more quickly with it ...

Reference counting isn't very difficult to use... there are some simple rules to follow , of course, but frankly it's not a so big annoying point (in fact for many people it's even a plus !). Good case study, GNUstep supports the use of a garbage collector instead of the retain/release ... but almost any GNUstep programmers/programs uses retain/release (the only exception is GNUstepWeb which uses in some parts of it garbage collecting).

see http://www.stepwise.com/Articles/Technical/HoldMe.html
for a good article on retain/release.

Don't focuses on retain/release, it's not worth it, and you'll miss the quality of OpenStep ... Wed, 07 May 2003 17:43:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? This series has been quite informative thus far, and has helped untangle some of the issues that have thus far kept me from getting anywhere with PB, IB, AppleScript Studio, etc.

You've cleared up some of the weirdness of ObjC syntax admirably. Now, if you can only help me understand how
to apply weird ObjC syntax to actually attaching methods to widgets (The connection between IB connections and the real code in PB?)

Either way,
Thanks Wed, 07 May 2003 19:41:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Hi folks,

The memory mistakes in my code have been fixed (along with some of the explanations), but I didn't convey the placement of the fixed paragraphs properly to the editor, so right now it's all a bit mixed up. But it's being taken care of right now, so, hopefully soon, everything will look right.

Sorry about that,

Jared Wed, 07 May 2003 21:05:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? If one is able to fix OS X .pbproj files to original .project files, then one is effectively able to run the same code on OPENSTEP, thus crossplatform to Intel, Moto, HP and Sparc architectures as well. Without the .pbproj conversion, you could still recreate the project yourselves: the codefiles are quite compatible if you don't use the Cocoa proprietary objects (which there aren't many) Thu, 08 May 2003 09:41:00 GMT donotreply@osnews.com (Anonymous) Comments