Slashdot Mirror
Cocoa Programming for Mac OS X, 2nd Edition
The author is no stranger to OpenStep, having worked at NeXT as well as Apple in OpenStep application development and training. Currently, Hillegass teaches Cocoa programming for The Big Nerd Ranch.
Cocoa Programming for Mac OS X, 2nd Edition is written in a way that makes you feel like you are in a class. There are prerequisites you must know and understand before you can begin, and, as a good professor would, the author points out what you need to have and know before beginning. Happily, the author is quite meticulous and has generously provided useful resource links and help where readers may explore for their supplies and primers and the like.
Essentially, anyone with a copy of Mac OS X 10.3 Panther has all that should be required--the Developer Tools CD contains all developer software and documentation necessary (the author notes in the book specific locations for key primers and references).
If you are experienced in C++ or Java programming, Cocoa development will seem familiar enough. Objective-C is used throughout the book (the author notes that development in Java is possible, but not recommended) for the various and numerous exercises. Cocoa development is made easier with Apple's Xcode application, however, Cocoa is not for the timid or novice programmer. This book is well-written and easy to follow IF you have a respectable level of C/C++ or Java development under your belt.
The text, as well as its diction, is easy on the eyes and mind, and while this is a programming book, the author's voice speaks well, allowing you to feel as if you can ask the book questions as if you were in a classroom. Graphics and text are plentiful, but information is not packed on every page, so following along is far from drudgery. Each chapter does stack itself on information from the previous, so this isn't a reference book in the strictest sense.
Addison-Wesley, the publisher, has formatted the book nicely, with a pleasant font that won't tire the eyes, consistent code and text conventions, and a detailed Table of Contents and Index, However, it's thickness and binding doesn't lend itself to lying flat, so you'll have to weight the book pages down to read the book hands-free as you type in examples. Speciality bindings that could have been useful for this book are not cheap, based on my publishing experience, and such a binding would add more to the book's $45 US cost. (Amazon has a great deal on the book at the time of this review.)
Five new chapters were added in this 2nd edition, which discuss creating AppleScriptable applications, integrating OpenGL, adding Undo abilities, creating reusable frameworks, and tinkering with GNUStep, the raw open-source tools for those curious about making Cocoa apps under Linux.
If you're a UNIX or Windows developer who picked up a Mac OS X machine recently in hopes of developing new apps or porting your apps to Mac users. this book should be strongly considered as one of your essential reference and training tomes.
You can purchase Cocoa Programming for Mac OS X, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
in realated news Dutch cocoa maker Godiva comes out with a book on properly programming your microwave to make the perfect drink.
Sig (appended to the end of comments you post, 120 chars)
...he mentioned Java because there's a Bridge mechanism in OS X that allows Java code to call ObjC code, and ObjC code to call Java code. I've used it myself and found it to be an effective way to write Java programs that are native to the OS X platform. Be warned, however. Differences in the way ObjC and Java handle objects causes quite a bugs. Not everything can be 100% mapped, so you'll find yourself writing some ObjC anyway.
Javascript + Nintendo DSi = DSiCade
How different is this one from the first edition?
"Cocoa Applications" (excellent step-by-step guide) and "Learning Cocoa with objective C" (more focused on the language than the framework). These are both from O'Reilly and recommended by the ADC (Apple Developer Connection).
Simon
Physicists get Hadrons!
Real men code everything in BASIC.
I'll wait for the third edition: Protocol Handler Exploit Programming for Mac OS X.
taken! (by Davidleeroth) Thanks Bingo Foo!
I've read several of the other Cocoa books out there and Aaron's is the only book that intelligently steps you through adopting this language and the design metaphors that Apple encourages you to adopt to build applications to best effect that leverage all the capabilities of the system foundations versus trying to do everything yourself.
The additions of covering bindings is just how to get around the new Xcode interface including the revamped Interface Builder makes this book a must read. Starting with any of the other books you'll be banging your head against the wall as what you see and what they describe in terms of many of the actions will not match the current tools.
http://www.bignerdranch.com/products/cocoa1.shtml
We Bash Back
kookoo for Cocoa Progs
Real men code everything in assembly
Evolution or ID?
I read through the first edition about a year ago, and found it to be an excellent hands-on tutorial, gradually walking the reader through the construction of increasingly complex apps. I came at the book from a strong C++ background and various Microsoft technologies, and zero experience with Mac software development, and left with a reasonable beginners knowledge of Objective-C and Cocoa. Supplement this tutorial with resources like Apple's reference material and the mindshare at the Cocoa developer list archives, and you'll be well on your way to developing your first Mac app.
I'm glad to see that the second edition added AppleScripting and material on implementing Undo, even if at the expense of the Java chapter. (No surprise, there: in the beginning of the first edition's Java chapter, Hillegass basically says this about programming Cocoa using Java: "DON'T.")
the cocoa, cocoa cabana....
Evolution or ID?
Can Cocoa use the same objsect code produced in Mono?
Evolution or ID?
From what I've heard Apple is taking this more seriously than Microsoft.
... jeeze... getting on for a decade ago, and that about nine out of ten email viruses and worms exploit, and that Microsoft not only refused to fix but spent five years in lawsuits with the justice department to defend... even though every other person in the security business was telling them it was a bad idea.
After all, this is the same basic design flaw that led me to ban IE and Outlook at work about
HEY, PEOPLE, DON'T USE THE SAME PROGRAMS AND HELPER APPLICATIONS FOR LOCAL DATA AND THE INHERENTLY UNTRUSTABLE INTERNET!
Sheesh. This isn't rocket science. Hopefully Apple has some rocket scientists and won't spend the next decade patching one hole after another.
Real men don't care WHAT the real answer is...instead, they choose one at random and beat the shit out of anyone who disagrees.
Which is why true && false == true. What, you wanna start? BRING IT ON!
Hey freaks: now you're ju
I was browsing the second edition at a bookstore (I own the first edition), and the the Java chapter seems to be replaced with a chapter on GnuStep. Maybe I'm reading it wrong, but it seems he basically has the same advice, saying something about GnuStep being announced 10 years ago and still not at a 1.0 version, and also being both difficult to install and a bit buggy.
I think he puts these chapters in his book only to answer the question, "I wonder what Hillegass thinks about coding in such-and-such."
quiquid id est, timeo puellas et oscula dantes.
Why did apple choose to use Objective C? Why not just use C++? What are the differences? Is objective C more like C#?
ZX2C4
From this review it says that the book starts out with how to start a Cocoa application project with Project Builder
Where are the Xcode books???
I'd love to see a "more up to date" version of this that deals strictly with using Xcode. That seems to be the tool of choice for the OSX Cocoa developer's future.(imho)
http://slashdot.org/~tf23/journal
I'm a Java programmer, and used to program Mac's in the system 7 era. So, I thought I'd take a look at using the Cocoa API. There is a java-cocoa tutorial on apples developer site, so I fired up x-code / Gui Builder and jumped in.
After spending a good few hours understanding how to develop in this environment,I honestly think that the effort and pain needed to put together this simple currency converter app, is not worth it.... I could have done the same thing in any other environment (Swing/VB/ old Res-edit & Pascal), in minutes... What is the big deal surrounding MVC for a GUI?
Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing).... What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?
I was an consultant for Apple back in the heady days right after NeXT acquired Apple, when Jobs was Apple's "interim CEO" (the term "iCEO" hadn't been coined yet). I had the good fortune of taking a class taught by Aaron on advanced WebObjects programming.
He struck me then as someone that falls into the category as a "Big Brain", esp wrt to training/educating on software programming. And a super nice (and patient) guy, to boot.
I'm gonna pick up this book asap.
---anactofgod---
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
Here's an openstep workalike for linux, they even have "Project Builder" and "Interface Builder".
GNUStep project
useful for getting your feet wet with Objective-C (pretty good) and the *step frameworks.
Real Programmers don't write specs -- users should consider themselves lucky to get any programs at all, and take what they get.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write application programs, they program right down on the bare metal. Application programming is for feebs who can't do system programming.
Real Programmers don't eat quiche. They eat Twinkies. And Szechwan food. (Do not go to eat Szechwan food with a group of Real Programmers unless you are prepared to argue bitterly over the last spring roll.)
Real Programmers aren't scared of GOTOs... but they really prefer branches to absolute locations.
Real Programmers don't write COBOL. COBOL is for wimpy application programmers.
Real Programmers' programs never work right the first time. But if you throw them on the machine they can be patched into working in "only a few" 30-hour debugging sessions.
Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies.
Real Programmers never work 9 to 5. If they are around at 9 AM, it's because they were up all night.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC... after age twelve.
Real Programmers can take the scissors off the phone cord.
Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.
Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room.
Real Programmers don't do documentation. Documentation is for simps who can't figure out the listing.
Real Programmers don't write in PASCAL, or BLISS, or ADA, or any of those pinko computer science languages. Strong typing is for people with weak memories.
This book combined with "Learning Cocoa with Objective-C" and AppKiDo is invaluable for a novice Objective-C programmer.
However...
Complete knowledge of the AppKit and the Foundation is essential to writing good Cocoa programs (To a lesser extent CoreFoundation (horribly documented!) and Carbon). There are plenty of objects I found post-facto that would have made my life easier had I known they existed. I have yet to find a single book that does this well.
Currently, the best way to start developing (and gain the kit knowledge) in Cocoa is to read these two books and then just try and develop a program, all the while stopping and searching AppKiDo for useful objects that you think may exist.
While the building is on fire.
O'Reilly... a well respected publisher (and have bookshelf full of their titles) and Addison Wesley.. another respected publisher.
Which one to choose if you could only choose one? Thanks.
Among the things he adds in the 2nd edition is a piece on NSController, a neat feature that saves you a ton of time you'd otherwise spend creating GUI glue code between your view and controller layers. He also includes some info on creating frameworks, which is kind of hard to come by in most mac programming books.
Ergonomica Auctorita Illico!
Ah, so they have Java and Cocoa now, eh? In that case, I have just one question for you:
Cream or sugar?
* Perhaps today is a good day to die... I say we ship it."
* Specifications are for the weak and timid!!
* This machine is a piece of GAGH! I need dual Pentium (!) processors if I am to do battle with this code.
* You cannot really appreciate Dilbert unless you've read it in the original Klingon.
* Indentation?! I will show you how to indent when I indent your skull!
* What is this talk of 'release'? Klingons do not make software 'releases'. Our software escapes, leaving a bloody trail of designers and quality assurance people in its wake!
* Klingon function calls do not have "parameters" - they have "arguments"- and they ALWAYS WIN THEM.
* Debugging? Klingons do not debug. Our software does not coddle the weak.
* I have challenged the entire Quality Assurance team to a Bat-Leh contest! They will not concern us again.
* A TRUE Klingon warrior does not comment his code.
* By filing this bug report you have challenged the honor of my family. Prepare to die!
* You question the worthiness of my code? I should kill you where you stand!
* Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
(sources too numerous to attribute)
---anactofgod---
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
I perfer Cocoa Programming by Scott Anguish. It is a great Cocoa book as it describes many aspects of Cocoa, not just making a GUI like most books I've seen. It describes the philosophy, principles, design, and even implementation of Cocoa. It is more in-depth than any Cocoa book I've seen. It is the only Cocoa book I know of that contains more than 1000 pages. And as for value, it is an invaluable reference to any Cocoa programmer and the cost is not much either as you can find it in some outlet book stores for about twenty dollars. I would certainly recommend Cocoa Programming to anyone interested in developing for the Macintosh OS Ten.
"...porting your apps to Mac users..."
:-)
Interesting idea. I thought most Mac users had to be programmed in English, though.
If you are experienced in C++ or Java programming, Cocoa development will seem familiar enough. Objective-C is used throughout the book.
Are you saying that familiarity with C++ or Java is sufficient to learn Objective-C with no further effort? Or perhaps you're saying that the book teaches me how Objective-C along with Cocoa?
Without some sort of clarification, the two sentences above seem rather contradictory.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
It does not look like even the first edition of this book is on Oriley's Safari site (they do have other Addison-Wesley books), which is very unfortunate. Hopefully with the new update they'll consider moving the book online.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I like to smash and bash the Amazon-sponsor-link trolls as much as anyone, but this has no referral link in it. The "ref" completely valid -- in fact, try it yourself from the main Amazon page. You'll get it.
To spot referral links, look for the string "-20" after a suspicious looking username, like "ccats-20". That's your tip-off.
What ever happened to creating binaries from scratch in a hex editor??
Are the food jokes about Cocoa (and Java) really still amusing? Or were they ever? There's enough derivative/inflamatory crap on this site without having skim over peoples lame-ass regurgitated humor...
So I looked on that site and found Gorm (Interface Builder), but where exactly is the project builder clone?
Dan
After spending a good few hours understanding how to develop in this environment,I honestly think that the effort and pain needed to put together this simple currency converter app, is not worth it.... I could have done the same thing in any other environment (Swing/VB/ old Res-edit & Pascal), in minutes... What is the big deal surrounding MVC for a GUI?
As could I with xcode/IB.
Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing)....
Sure.
What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?
If you feel you need to write code to do that, you're doing something wrong. You should be able to drop something like that into your screen in ZERO lines of code.
...
Oh well.
One thing that is recent and got put into GCC 3.4? is Objective-C exception handling with @try @catch, @throw. Is this in the new book?
I can't find the message in the GCC mailing list about which version introduced objective C exceptions.
You can implement rather complex GUIs without writing a single line of code yourself (more so now thanks to the contoller objects supported
Recently wrote an article on this, for those that are interested:
Introduction to Bindings
- Scott
Scott Stevenson
Tree House Ideas
... you get screwed up by C++.
Well, OK, not screwed up, but C++ experience should not be considered a good background for learning Objective-C Cocoa. Its approach to programming with "objects" is very different, and the transition to Objective-C, IMHO, leads to a mix of techniques that is hell to read/debug, making for buggy Cocoa apps. If you're a C++ vet, it may be a good idea to unlearn a lot of what you know, and assimilate the conventions of the seasoned Objective-C coders.
That said, even though C++ may not give you a good start for Objective-C development, it can still be very beneficial to leverage C++'s speed in various parts of your application. You can, for example, build your engine from C++, and your widgetry in Objective-C Cocoa.
A strong Java background makes for a fairly easy to transition into Cocoa, trading in a few conveniences for greater flexibility, more mature classes, and easy GUI development. Java is quite similar to Objective-C and both can be used/mixed to build Cocoa applications (most don't though).
If you're a C jockey, Objective-C is like adding a new weapon to your arsenal. Objective-C is a superset of C. Those who are fluent in the design patterns of both languages will get the most from their Cocoa applications. Indeed, the ability to (fairly) freely intermix C, Objective-C and C++ is a great advantage, allowing you to use the tool that's right for the job.
As a switcher from any language, one of the biggest hurdles can be getting some fundamental OO design patterns down, which are expected by most of the Cocoa API. For example, you can't go one step in learning Objective-C without being taught the MVC (Model-View-Controller) paradigm. In contrast, a great many mature Java/C++ developers have never learned, or even heard of, this concept.
Just some observations... YMMV.
do you not understand? Geez, Objective C is used because it's different. It's also better as is all things that Apple does. Even when Apple gets them from somebody else and said it was stupid before they got them. Objective C is good for you. Shut up and drink the koolaid.
I think Spencerian probably answers 90% of the questions most people have about this book: author qualification, tools required, prequisite expertise required, and changes from the original. I won't get involved in the flame wars about Objective-C versus Java and Mac OS X versus GnuStep, but I do have some additional comments (maybe better stated as additional opinions).
Tools:
You must have Panther (10.3) or later to use this book. It was possible to read the first edition (written for 10.1) and make some mental leaps forward, but the reverse is impossible. Besides the differentces between XCode and the GUI screenshots, Apple deprecated a number of methods (like takeValue:forKey:) in favor of much cleaner names (e.g. setValue:forKey:). Aaron doesn't mention the deprecated names (quite rightly IMHO) so that will make the Jaguar programmer have to refer to Apple's website to do the translation back to the older APIs. You may need to do mental exercises like that when you have to read someone elses code or when you're back porting your app, but if you're still learning, be sure to get Panther before trying to use this book.
Presentation:
Many of the books screenshots look much cleaner than the prior version. I think that's mainly attributable to Apple deciding to tone down much of the visual clutter in the Aqua theme. The lack of the pinstripes in windows and menus really makes the documentation much easier on the eyes. The change is really much more dramatic and makes for a much more readable book.
If You Read the First Edition:
I've read the first edition, and I have to say that I got impatient with much of the earlier portions of the book. I wanted the examples for Bindings and other new additions to Cocoa. I was already comfortable with the trivial examples in the early chapters, so it was hard to force myself to go back and really read and work through them. Do it. I remember most of the big points made, but some of the subtler points make more sense now. Whether these were in the last edition, I'm not certain but it was still good a good review.
Applicability to a New Programmer:
I'll underscore that this isn't for a new programmer. If you are new to C, I'd suggest reading the non-GUI text "Programming in Objective-C" by Stephen G. Kochan. An extensive background in object-oriented programming isn't as necessary (and in fact may be detrimental if your background is multiple inhereitance of the C++ world). But it does include some tips and advice on good OO techniques that Objective-C programmers use. You won't see any explanation on pointer tricks, handles, NULL, or many of the other plain C conventions. If you are a strong Unix programmer, you may feel more comfortable reading the Aaron Hillegass and Mark Dalrymple's "Core Mac OS X and Unix Programming" first. That book is billed as the sequel to this one (and it does use a little bit of Objective-C code), but it probably addresses your interests far more than this Application-centric book does.
The lessons of this book are quite worthwhile to certain audiences, but finding whether you are a target for it's wisdom may be tricky. Don't get frustrated. If you find it to be over your head, read another intro book but I'd definitely come back to this one at some point in the future.
The Currency Coverter is really designed to show this pattern at it's most simple. Sure there are all sorts of short cuts you can take if you are really writing a simple currency converter, but the point of the exercise is to show those people who already find value in this common pattern how to go about doing something this basic.
Actually, there's another book that many Cocoa programmers should probably check out besides the Gamma book. It's an Addison-Wesley book called The Design Patterns Smalltalk Companion and it's pretty easy to make the mental leap and convert their design advice to Objective-C. (There are other books that probably do this better if your interest is Java).
As an aside, there's a lot of great advice in these two books that Apple clearly had in mind when developing Cocoa. As much as I brissle at the original poster's comment about the "value" of MVC, it disappoints me how few Cocoa programmers recognize their applicability. Please don't limit your Cocoa education to simply books that have Cocoa in the title.
One does not really need to know C++ nor Java as Objective-C is really ANSI C + Smalltalk extensions. Obj-C on it's own is really rather simple. It's much easier and some may argue more powerful then Java or C++.
What this book does is introduce you to the Cocoa API and the Apple Dev Tools XCode & Interface Builder. The first edition was a blast and I plan on picking up the second edition in the near future.
If you are coming from a C++ background and you like it, you should study Carbon and not Cocoa at first. You can call Cocoa objects from Carbon and visa versa though. New projects should probably be written in Cocoa. Older projects written in C++ can be ported to Carbon easily. C programs can be ported to Cocoa and Java programs should probably stay Java or be ported to the WebObjects frameworks if it's a web based solution. You can write Java apps using the Cocoa API but it then becomes locked into the OS X platform as the Cocoa API (for Java) is not available on other platforms (maybe GNUStep but it's not all the way there yet) Note, you can run Tomcat and JBoss on OS X!
The NeXTStep / OpenStep / Cocoa API is rather advanced and can take some getting used to... i.e. you will have a rather steep learning curve to absorb it all and understand the best practices. This book is a great introduction and will get one up to speed quickly.
I found Interface Builder to be the most difficult part of the development process. This was because I had to unlearn all the preconceived crap in my head that I learned from other GUI interface tools. It turns out IB is much more advanced then anything I've ever used before because it builds live objects and not just GUI code. It then archives these objects into NIB files which are automatically unarchived by a Cocoa application. You literally build objects graphically and then interconnect them to each other and your Obj-C classes and instances. WebObjects does the same thing but with Java. It's a really slick development tool and once you start to understand it, the light turns on and you can see the possibilities.
Total newbies should probably pick up the "Programming in Objective-C" by Stephen Kochan. This book covers just the underlying Obj-C language and the Core Foundation (NeXStep/OpenStep/GNUStep/Cocoa) API. Programming in Objective-C does not cover the GUI portion of Cocoa programming. I just finished it and it managed to bootstrap my understanding quite a bit.
I have the first edition of this book, and found it to be excellent. I'd consider it the first of two essential books for Cocoa programming (the second being the O'Reilly book, which I use as a class reference).
I've seen the list of what's been updated, but it isn't enough to convince me that getting the second edition is worth the price if you already own the first. Are the differences enough to warrant the additional investment?
--
Welcome to the land of the easily amused...
Right, here's a question that pops into my head whenever I see references to Cocoa/Carbon on slashdot...
See, I've written some libraries that I use to write my apps, and I deliberately chose to make them portable, in case I ever decided to switch from Windows to Linux or Mac OS X - so I wouldn't end up losing all my software (or having to put a lot of work into porting them).
So I have APIs for general OS interface and GUI programming, which I designed to be portable, having passing familiarity with Linux and Mac OS APIs. The libraries are currently implemented for Windows, but I try to wrap Windows specific functionality in a generic 'GUI' way (something I wish other libs would do a bit more, wxWindows I'm looking at you).
Anyway, the libraries have a C++ interface, and are implemented in C++ on top of Win32.
My question is: if I want to create Mac OS X versions of these libraries, should I use Carbon or Cocoa?
My understanding is that both will work, but Cocoa is the nice shiny API that does all the clever stuff, and Carbon is being phased out, and I shouldn't use it. So new UI widgets, dialogs, various functionality have clean, comprehensive implementations via Cocoa, and Carbon is a sort of DIY solution if you want to use the new stuff. I'm also not sure how well IB works with Carbon (if at all).
But: Cocoa seems heavily oriented towards Objective C. It seems possible to mix C++ and Obj-C in an app, but how feasible is it for me to implement a version of my lib that exposes a C++ interface, yet uses Cocoa/ObjC internally? And even if it works, would it be full of nasty hacks?
If any Mac programmers can offer me any insight here, I'd be grateful.
Please note that such insight does not include "You should just use Objective C for everything", just to warn you in advance. I use C++ because of its ubiquity, my familiarity with it, and the large amount of code I already have that uses it. Objective C might be absolutely wonderful, but as all I ever hear about it is this fantastic new (sic) idea called MVC, it's hard to tell :-)
If I'm going to learn/use a different language, I'd rather try something really portable like Python. Objective C still seems like an 'oddball' language to me, that's only used on Macs. While I want to support Macs with my libraries, I'm not re-architecting and re-writing the whole lot just because Apple decided the preferred interface to their OS/GUI was an OO interface, and they wanted to use Objective C, because NeXT used it.
Thanks....
you're koo-koo for negro cockz
You might think so, but when I worked at NeXT, he was creepy. He started stalking me around the office and eventually he moved into a condo right across the street from me. Fortunately, I got a new job in San Diego and that was the last I heard from him.
It's a common misconception, but neither of those games were ever written in Objective-C. Here Carmack talks about it:
i t_ info.html
k eEd/source .html
http://www.gamers.org/dEngine/quake/QuakeEd/qed
And here's the code for QuakeEd:
http://www.gamers.org/dEngine/quake/Qua
I can't find the references for Nuclear Strike right now but it's the same case where the Map Editor was written in Obj-C.
Do you know if this addition is from Apple or from the GNUStep people? If it's not an Apple sanctioned addition to the language, it probably won't be in the Cocoa spec.
It's in the Apple docs for Objective-C.
- Scott
Scott Stevenson
Tree House Ideas
If you could point me towards a source that has the KVC Currency Converter example written in Java I would be extremely grateful. Apple KVC Obj-C Sample
I can't seem to find an interface anywhere that provides the method setKeys(), which results in none of my classes being key value coding compliant.
It's a shame, because the Cocoa controllers look amazingly useful. I guess I've found out why the book recommends using Obj-C :(
Java seems to be a second class citizen in Cocoaville.