Here is an introduction to the style of Objective-C Cocoa and some reasons why the author at Kuro5hin hopes more programming will be done in this style in the future.
Introduction to Cocoa with Objective-C
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’ve written a nice objective-c tutorial as well, with lots of source code examples. it’s at http://www.otierney.net/objective-c.html
Excuse me ?
some classes are missing (nsdrawers …), but the majority of the classes are implemented… rather difficult then to say it’s “not nearly so complete” …
“some classes are missing (nsdrawers …), but the majority of the classes are implemented… rather difficult then to say it’s “not nearly so complete” … ”
“Not nearly so complete” is a polite and exact expression!
And anyway, are the html kit classes ready?
https://gna.org/projects/gswebkit
seems to be coming alog nicely from what i’ve heard.
just read how positive the people who commented on that link are on that page! They make osnews seem polite by comparision!
With the exception of some C#/.Net development i’m doing right now, all the work im doing is entirely in Objective-C/Cocoa. I’ve found Objective-C to be a very easy, flexible & advanced programming language that can suit all your needs. Combined with Xcode you simply have an excellent development environment and you can easily manage project files much better than Visual Studio 6 or .NET. Whenever possible im using Cocoa/Objective-C for Mac applications.
Of course Xcode & Cocoa isn’t perfect, but it’s the closest thing to perfect for me.
So far, I haven’t seen much in Cocoa/ObjC that I haven’t seen in other object oriented framework/language combinations. That all controls inherit from the same base type, which itself inherits from a generic object type is nothing spectacular and a well-known and popular concept, and resource-based UI layout schemes are nothing new either (and I don’t like them for their inflexibility when it comes to changed font faces or sizes).
Honestly, I cannot understand all that excitement about Cocoa. It doesn’t do your laundry for you or magically make your application more usable, it’s just another OO framework.
“Honestly, I cannot understand all that excitement about Cocoa. It doesn’t do your laundry for you or magically make your application more usable, it’s just another OO framework.”
On the second most popular consumer desktop machines. Throw in the nice developemnt environment, and woo hoo.
Honnestly, it’s because you didn’t developed with it. It’s much better than most of the OO framework, because it heavily uses many design patterns such as delegation, composition, mvc, etc.
check things like the responder chain … or NSTableView delegate …
It’s just very well done and thought. The single fact that Apple didn’t updated it much since 1994 should speak for itself (they mostly added widgets).
The fact that it runs on OSX is irrelevant — that’s not why it is good. It was good on OPENSTEP, it’s still damn good on Mac computers now.
It doesn’t do your laundry, but it’s not far — the whole idea of OpenStep frameworks was to let you fit your program “in” the framework. Basically, the idea is to use the existing code, not to force developers to inherits some widgets (tables..) for their need. You rarely inherits widgets in Cocoa — and that’s a good thing. The less code, the faster you program, the less bug you have.
Plus, InterfaceBuilder is an incredible RAD tool — you aren’t that far from a pure designing click-and-run programming. Yet you still has all the power of normal programming — it’s not dumbed down programming, it actually HELP you and save you time.
You could also check Gorm, the GNUstep equivalent of IB.
I’m going to use o-c with gcc.
Your tutorial is really great.
thanks thanks
Why so many think GNUstep should be used for porting Cocoa apps?
I see GNUstep is a ready and complete enough development platform
which I can start doing many interesting things with it. Do I ever need
a specific functionality that only available on OS X? Honestly, no.
http://www.oreilly.com/catalog/objectcpr/index.html
is enough to learn Objective-C (if you already know C)
Cocoa/GNUstep have lot of design patterns builtin :
http://hillside.net/patterns/DPBook/DPBook.html is a reference.
http://gnustep.org/experience/documentation.html
contains some intersting links too.
Why is Cocoa so exciting?
First, it’s a wonderful OO framework. Compared to other frameworks, it has a different flavor, thanks to its Smalltalk roots. It’s quite refreshing to be freed from all those constraints you have in C++ or Java and to deal with other paradigms, other ways to interact with your objects. It gives a instant feeling of freedom and power. And much fun.
But I would say that the most exciting thing with Cocoa is Mac OS X itself. Each new version of Mac OS X brings exciting innovations (e.g. Rendez-vous, new GUI elements, WebKit, Quartz etc.). Cocoa let you access this new technologies so easily that, for a developer, it is a very exciting environment. Cocoa is a bridge between you, the developer, and this stream of innovations you find on OS X. If you are excited by Mac OS X, then you become excited by Cocoa because it is the native object-oriented application framework that gives you access to OS X’s wonders in a flexible and powerful way, thanks to Objective-C.
Objective C. Do us all a favour. If you want to do OO programming, use a lanuage designed to be object oriented from the start.
Honnestly, it’s because you didn’t developed with it.
I have developed software with Cocoa/ObjC, but that didn’t excite me much. It may be exciting if you only used Win32 or Mac Toolbox before, but for someone who has used other OO frameworks before, it’s hardly revolutionary.
Oh, sure. It just depends what you are talking about. If you are speaking about SmallTalk, I could understand your point
If you are speaking of Qt and Java, well … Cocoa just seems cleaner. The ironic thing of course is that both Java and Qt are quite inspired by Cocoa (well, to be more correct, by OpenStep).
I guess then you don’t consider c++ a good OO language? because it is DEFINITELY as much of an extention (more so) than objective-c. the only from-the-beginning object oriented languages today are java, C#, python, and ruby.
the only from-the-beginning object oriented languages today are java, C#, python, and ruby.
Well – if we are getting picking then you should not include Python given the fact that you can write procedural code. For example:
echo ‘hello’;
No main method, no class etc.
“First, it’s a wonderful OO framework. Compared to other frameworks, it has a different flavor, thanks to its Smalltalk roots. It’s quite refreshing to be freed from all those constraints you have in C++ or Java and to deal with other paradigms, other ways to interact with your objects. It gives a instant feeling of freedom and power. And much fun. ”
I’d be interested to know what constraints C++ or Java imposes, that Cocoa doesn’t.
easy. objective-c has a root type, id, unlike C++. so writing functions that take multiple types doesn’t mean you have to write root interfaces for two classes, and you don’t have to make your own custom base object type for the entire project (which isn’t advisable anyways in c++). templates are a fancy macro, and i don’t think fancy macros are a good solution when you’re attempting to do object oriented programming. the id type has other useful features like multi-type checking at once. say you have two interfaces, one for printing and one for drawing, you can do typechecking on these to using the type id <Printing, Drawing> varName; so now varName accepts objects that confrom to those two interfaces (or protocols in objc).
another thing that c++ doesn’t let you do is “blind message calling” say i have a method named print in two objects..
id var = obj1;
[var print];
var = obj2;
[var print];
this is perfectly legal in obj-c because of the way messaging passing works. this allows you to do some highly dynamic programming. even java doesn’t allow you this sort of flexibility.
obj-c also lets you add methods dynamicly to already existing classes. NSArray (the foundation array type) has a sort method, but it has no reverseSort method. well, you can simply add that yourself!
@interface NSArray (Reverse)
-(NSArray *) reverseSort;
@end
@implementation NSArray (Reverse)
-(NSArray *) reverseSort {
// do sort here
}
@end
putting that code into a .m (instead of .cpp) and .h file, then #importing it to your source instantly gives you access to these new methods you just added to the base foundation. these are just a FEW of the things you can do in obj-c that neither c++ nor java support. hope that answers some of your questions.
> I’d be interested to know what constraints C++ or Java
> imposes, that Cocoa doesn’t.
A few examples to give you an idea:
– You can add methods to a class for which you don’t have the source code. This is one of the more useful feature of Objective-C. Great flexibility when dealing with existing frameworks or Cocoa itself.
– You can have heterogeneous collections (impossible in C++) and use them without downcasting (something you need to do in Java).
– You can manipulate an object without knowing its type. For instance, a button can be configured to invoke, when clicked, any method you want on any object you want. The button does not have to know the type of its target. This is flexible, easy to use, it avoids you a lot of hassle.
– You can replace a class by another at run-time.
– You can change the class of a particular instance at run-time (under some limitations).
– You can invoke a method on an object even if this object does not implement the method. The object will be given the chance to examine the method invocation and deal with it in the way it want (for example, forwarding the invocation to another object etc.)
– You have a real meta-class model. That is, classes are themselves objects (i.e., instances of other classes, called meta-classes, which are themselves objects etc.). You can define methods applying to classes, and use classes as any other objects (e.g. store them in collections, pass them as arguments to methods or functions etc.)
– A lot of fun and high-level design pattern are made possible by the dynamic typing of Objective-C, and many design pattern used in Java or C++ are simply made irrelevant because many of them are just complex tricks to work around the constraint imposed by static typing.
– Etc. Etc. Etc.
Not to say that Objective-C is better on all accounts (for instance Java garbage collector is infinitely better, in my opinion, than Objective-C semi-manual reference counting system). Just that it is based on a very different, refreshing programming model. Again, the first feeling I had with Cocoa was a feeling of freedom and power.
I would advise anyone interested in programming to look at Cocoa and Objective-C. Along with its development environment (Xcode, Interface Builder etc.) it provides a great programming experience.
Your second point sounds pretty cool, but I’ve never been convinced of the utility of Objective-C’s level of dynamic binding. It has always struck me as a debugging nightmare.
“- A lot of fun and high-level design pattern are made possible by the dynamic typing of Objective-C, and many design pattern used in Java or C++ are simply made irrelevant because many of them are just complex tricks to work around the constraint imposed by static typing. ”
Can you describe one of these? I’m certainly not a very experienced programmer but I’ve always looked at Design Patterns as one of those “Do you really need to do this?” type things. Sometimes necessary, but also quite burdensome (can add too much resource overhead).
obj-c does throw errors with improper message passing (if i’m not mistaken it is a halting operation) but that’s what methods like respondsTo: @selector( methodName ) are for. it lets you double check things before calling so you don’t hit that sort of wall. plus you can get compile time checking by making id <ProtocolName> types, or just BaseClass *varname types, which also do type checking. you get the best of both worlds though
Actually, of that list, only Ruby truly fits. Python feels a bit hackish when it comes to OO, not because you can write “procedural” code (I can write puts “hello” as a Ruby program), but rather for other reasons that are difficult to go into in an OSNews post.
Neither Java or C# truly fit either, because though both have or will have auto-boxing for primitives, those still are primitive types.
Of course, the purely (not so much as Ruby, though, and not in quite the same way) OO language missing from your list is Eiffel.
@omnivector: the only from-the-beginning object oriented languages today are java, C#, python, and ruby.</>
Dylan, Smalltalk, Self, Cecil, and a half a dozen others!
@Jason:
[i]I’d be interested to know what constraints C++ or Java imposes, that Cocoa doesn’t.
The harsh mistress of static typing
Can you describe one of these?
Peter Norvig has a good presentation where he describes design patterns in dynamic languages like Smalltalk, Lisp, and Dylan:
http://norvig.com/design-patterns/design-patterns.ppt
He points out how a lot of the traditional design patterns become either trivial or much easier to implement in dynamic languages. For example, in any language with multimethods, the visitor pattern becomes totally unnecessary.
I’ve always looked at Design Patterns as one of those “Do you really need to do this?” type things. Sometimes necessary, but also quite burdensome (can add too much resource overhead).
Design patterns are a very good way to improve your code. It allows you to apply the huge body of existing experience to your code, and by explicitly considering design patterns in your own design, you not only make the design more coherent, but make it much easier to describe to others who are conversant with these patterns.
“The harsh mistress of static typing
”
A lot of people have that attitude, but I fail to see where dynamic typing comes into play in any situation where the developer isn’t assuming the use of some interface anyways. Again, an example would shut me up, even a large one.
“Design patterns are a very good way to improve your code. It allows you to apply the huge body of existing experience to your code, and by explicitly considering design patterns in your own design, you not only make the design more coherent, but make it much easier to describe to others who are conversant with these patterns.”
That’s the GoF response, but I find it to be pretty dubious. This assumes that you understand the pattern well. Take PAC vs MVC for instance. AFAIK, they accomplish pretty much the same thing, but PAC leaves the presentation and abstration layers lighter-weight and more reusable since they aren’t directly coupled. But, do many people use the PAC pattern? I’m sure there are other examples of overbearing, overhyped, overused patterns.
I guess then you don’t consider c++ a good OO language?
C++ is by no means perfect, but it was actually designed to be object-oriented. Several years ago C++ was good for nothing really, but in the last few years compilers have come good and toolkits like Qt have made it much more of a pleasure to use. At long last, for a lot of uses, C++ has really matured. If you want to compile stuff natively, get it to run fast but you want to develop a largish, logically object-oriented system, C++ together with a good programming toolkit is your answer.
A lot depends on your programming methodology. Static typing makes an exploratory, incremental, style of programming very annoying. A static type system basically means you have to specify contracts between different parts of the program. While the program is evolving, these contracts are constantly changing. Thus, you end up spending lots of time fussing with type declarations that must be rewritten anyway. Now, this problem is lessened when you have type inference, but that makes polymorphism harder. A good dynamic type system (Lisp, mosts Schemes, Dylan) will let you specify types once you’ve got the design solidified, and you know what sorts of contracts you want to enforce.
Let me give you some concrete examples. Lately, I’ve been working on a Python program using GCC-XML. Its structured like a compiler, so its got an IR and various functions analagous to a backend’s code generator. Now, the backend recurses through the IR, running these generator functions as it goes. Each generator function is passed the node it needs to consider, as well as a reference to the entire IR in case it needs to look at some global info.
At some point, I decided I wanted to change the representation of the IR. Originally, I just had a pointer to the root node. I added some functions that built indexes of the IR, and wanted to pass those to the generator functions too. Now, in C++, this would have been a pain. I would have had to change the type declration of every single function that handled the IR. In Python, it was extremely easy. I didn’t have to change any declrations, only the places where the IR reference was used. Since nearly all of the generator functions only needed only local info, they never touched the IR reference, and didn’t need to be changed. In fact, even the functions that looked at the IR only did so through a few specific functions, so a major change in the design was accomplished by making only a few actual changes in the code.
Now, you could make the counter argument that I should have made the IR reference a pointer to an opaque structure to begin with, so I could have made the change more easily. That’s precisely what I would have done in C++. However, doing this introduces extra complexity that might not be necessary. Think of dynamic typing enables a programming model that does “just in time” introduction of complexity. Its like just in time manufacturing used by industry. You only do the work when you have to do the work, so as to avoid wasted work.
C++ is by no means perfect, but it was actually designed to be object-oriented. Several years ago C++ was good for nothing really, but in the last few years compilers have come good and toolkits like Qt have made it much more of a pleasure to use. At long last, for a lot of uses, C++ has really matured. If you want to compile stuff natively, get it to run fast but you want to develop a largish, logically object-oriented system, C++ together with a good programming toolkit is your answer.
think my point is, obj-c can do all those things and then some, plus it’s a simpler extention to the C language than C++. so it’s simpler, just as fast, and more powerful. it’s a shame it’s so unappreciated in the world of large commercial software because it fits all the gaps that c++ fills for systems that need speed and clean organization. objective-c++ (the obj-c to c++ bridge which lets you interface c++ libraries with obj-c programs) is unfortunately mac os x only at the moment, and i want to see this restriction lifted by the gnustep developers porting it over to gnustep (which works in windows/linux). would go a long way towards making obj-c the jack-of-all-trades c extention language.
objective-c++ […] is unfortunately mac os x only at the moment, and i want to see this restriction lifted by the gnustep developers porting it over to gnustep (which works in windows/linux). would go a long way towards making obj-c the jack-of-all-trades c extention language.
That’s not the job of GNUstep developers, but gcc developers.
Objective-C++ is a hack done by Apple on their own version of gcc. They contributed the code back to the gcc people at the time; the only problem is that, with Objective-C, you need a runtime. GNUstep uses the GNU runtime, while Apple uses the NeXT runtime. Objective-C++ needs some modifications on the runtime; logically Apple did the modif for the NeXT runtime, not for the GNU runtime. That’s why Apple gcc provides Objective-C++ while normal gcc doesn’t.
So, to have Objective-C++ on the normal gcc, you need to port the changes on the GNU runtime. That wasn’t done for gcc 3.3 because gcc people were redoing the C++ frontend; that wasn’t done for gcc 3.4 because of time; but it should hopefully be done for gcc 3.5.
In fact, Zemiowit Laski (an Apple engineer by the way) is actually working on it :
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00402.html
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00404.html
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00785.html
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00788.html
s/Zemiowit Laski/Ziemowit Laski , sorry.