[grannysmith]

i wonder how the programmers new to cocoa and objective-c think about the "new" language and the possibilities offered by cocoa. do you use java/objective-c mixed code? are you happy with the cocoa API? i'm very new in mac-programming in general and of course it's of interest to me what more experienced programmers think about all that.

thx & greets,
granny

[swcrissman]

For background purposes: I'm a student developer, and have several years experience working with C and C++, as well as a year or so of Java. I am completely new to Mac programming, beginning with X.

Now, my feelings about cocoa and objective-c are quite mixed. On one hand, I can look at the language and API, and really appreciate the elegance they have. I really think the features are top notch, and I can see how good they are.

On the other hand, I have a really hard time reading code written with them. This is mostly and ObjC thing, I guess. While I don't know much of the Cocoa API, yet, that which I know makes sense when I see it, so I assume the rest will fall into place as I learn more and more of the API. ObjC code, however, just seems to be really hard for me to wrap my brain around. I don't know if it is simply because the syntax is so different from the other languages I know, or if it is something about the syntax itself. Trying to read large chunks of ObjC code, though, can really throw me, although ironically, when I look at just a line or two, it seems pretty clear, and when working with objects of a class or type I havent used before, the function calls can make reading code much easier because of every parameter name being inherently available.

Overall, it's really won me over, when combined with the dev tools. Compared to the other IDE's and API's I've used, they are unmatched, and even unchallenged in terms of elegance, and clean implementation. The fact that they enforce good design/coding habits is just fuel to the fire. I just hope I get better at reading ObjC with more time.

I have not tried mixing the different code, or anything too fancy, being new, so I wont comment on those.

Spencer

[honeydew]

Background: I'm pretty familiar with C++ and have done some Mac toolbox programming in C many years ago, but nowadays Java is my strongest language. I've been experimenting with Cocoa and Objective-C during my weekends for the past 2 or 3 months.

It took me a little while to get used to the Objective-C syntax, but as a Java programmer most of the concepts are familiar. I also like how plain C is always available when I want to get my hands dirty. It's nice to get out of the Java "sandbox". No complaints here.

Cocoa is.. different. I've developed habits with Java's threading and event handling models that are hard to change. Little things drive me nuts, like the inverted coordinate system. Cocoa gives you much more "for free", but at the expense of being more structured. It is easy to get lost when you don't have a understanding of this structure and how it's components interact (responder chains, win/doc controllers, runloops, autorelease pools, etc.). There is a lot of power at your disposal, but the learning curve is steep.

Documentation. Java was easy to learn because the API had excellent hyperlinked documentation, examples and tutorials, all centrally located. You could stop by the local bookstore and browse dozens of Java books. Cocoa isn't quite there yet. Or may never be.

Tools. I love Interface Builder. IB is what got me interested in Cocoa, actually. It's fun to design a UI first and then figure out how to make it work. For the most part IB stays out of my way and lets me be creative. Project Builder is nice but still feels clunky. Again, it comes down to documentation. The Help Viewer is horrible. And can we have auto-completion? With inline documentation? Ah yes, Java IDEs have spoiled me.

Overall, I'm happy with Cocoa and Objective-C. The syntax is messy but the concepts are clean and powerful. The learning curve is steep but worthwhile. Whenever I have my doubts, I just glance at the Carbon API. *shudder*

[grannysmith]

thx for comments - i bought the book 'learning cocoa' a few days ago. just have to complete the tutorials ... i'll do pretty much with java because of beeing a stundent (computer science) and wanted to learn objective-c as an additional language to java and my little c/c++, realbasic, php, perl -knowledge ... while all those languages look very similar in syntax objective-c is really different. but if you think it's whorthwhile---

greets,
granny

[Amorph]

You would do well to look at languages like Smalltalk (especially), and Scheme (the language the powers EMACS). Even MUSHcode, which is based loosely on LISP. Once you're familiar with those, Objective-C will be a lot easier to read. Its message-passing syntax was inspired by Smalltalk.

[mmj_ngen]

I've been trying to play with Cocoa since march, and I'm just finding the time. I'm a Java and C++ developer...well more Java than C++. Objective-C and Cocoa are a little weird for me, but not that weird. It's just another language and dev environment for the most part. I like how easy Cocoa makes it to implement certain functionality, but some of the fundamental concepts Objective C seem questionable, even dangerous, like categories. It's probably because I'm not familiar with the language though. I like the environment, but, at this point, it's not something that I'd go out of my way to work with. Maybe I'll change my mind as I work with it more.

[Porfiry2001]

Categories are one of the most elegant features of Obj-C. They might not be terribly useful for your own code (if you want to add functionality, it's no problem since you have the source code), but if you want to add additional functionality to someone's compiled code (like the Cocoa classes), categories are exceptional.

One really useful application of categories is for adding simple convenience functions to a class. The typical example is the NSString class which, even though it is incredibly useful, may still lack some small function you need. Check out the OmniFoundation framework for some examples of category usage.

Finally, because many Cocoa classes (like NSString, NSDictionary, NSArray) are in fact abstract -- the real implementation is hidden as a private subclass -- you CANNOT subclass them easily. The only way to extend the functionality of some of these classes is using categories.

[Angus_D]

I too am quite new to Cocoa. By that, I mean I haven't been following it on NeXT and so on, I jumped on the bandwagon with OS X. I have been fooling around with programming for a few years, with varying degrees of success. I started fiddling around with HyperCard many moon ago, then started trying to learn other languages like C, but was put off by the amount of code needed to display a window using the Macintosh Toolbox.

A few years after that, I came across REALbasic 1.0. I followed that for a while, purchased 2.1.2, used it for a few small projects... But after a while it became apparent that it had limitations. It was too slow, bloated, buggy and I could see that in the real world, REALbasic experience is not that useful.

I played with Cocoa a bit under the Public Beta, but I didn't grasp it. I then went off to learn more about the UNIX aspect of Mac OS X and Darwin, and I have since become a developer on GNU-Darwin (http://www.gnu-darwin.org/) and Fink (http://fink.sourceforge.net). I went back to OS 9 for a bit, mainly due to the lack of apps for the public beta, and contemplated learning Carbon. However, there were no books around for Carbon, and the closest thing I could find (and free) was the Macintosh C tutorial from MacTech (http://www.mactech.com). I wasn't going to learn the Toolbox at this stage, since it was going to be obsolete. I did, however, cobble together my own app which displayed a window and drew into it

When OS X 10.0 rolled around and had the tools in the box, I took up Cocoa more seriously. Since then, I have been playing with it, and I'm pretty knowledgeable about it. I have never used a book (apart from Rhapsody DiscOS, a bit, I did TravelAdvisor and so on), but I already knew OO fundamentals and a bit of C, which helped.

So that brings me to today, where I'm currently writing a GUI frontend to Fink. This also requires implementing some backending in perl (fink is written in perl), so I'm refreshing my perl skillz

Anyway, Cocoa is not quite as easy to use as RB, but it's definitely not far off, and is much more powerful, much faster, and creates much smaller apps (my fink gui is currently around 500 lines and 70k, in RB it would be about 1.5mb, and I wouldn't even be able to do it at all due to limitations in the shell class). I think I'll stick with Cocoa for a bit, but I'm also planning on learning some toolkits like GTK+, which look quite funky

Some of the Obj-C facilities like categories are very strange at first, but once you grok them you can really see the usefulness

[mmj_ngen]

Porfiry2001 wrote:

Categories are one of the most elegant features of Obj-C. They might not be terribly useful for your own code (if you want to add functionality, it's no problem since you have the source code), but if you want to add additional functionality to someone's compiled code (like the Cocoa classes), categories are exceptional.

I agree, they seem extremely useful. I can't tell you how may times I wanted something like this for Java in order to add onto final classes. But, it still seems dangerous. I may not necessarily want anyone to be able to extend certain classes. I'm sure I don't understand the limitations of categories, as in what they can and can't do, but they don't seem to have a limit. That's where it seems dangerous.

Should every class be able to be extended so any developer can add methods to a class? I don't know. To me, no, but that's just a difference in philosophy. My concern has to do with the comment in Object-Oriented Programming and the Objective-C Language: "Category methods can do anything that methods defined in the class proper can do. At run time, there's no difference..." .

Like I said, I haven't used it enough and definitely don't know enough about the language, so my opinion may change. That's just a first impression. It's probably a misguided impression. Please let me know if I misunderstood something about categories.

[Porfiry2001]

I'm sure I don't understand the limitations of categories, as in what they can and can't do, but they don't seem to have a limit. That's where it seems dangerous.

The limitation is that you cannot add instance variables -- only methods.

Additionally, a well designed publicly available class shouldn't be exposing its instance variables anyways. So, to do anything useful with a category, you'll be going through the methods of the class. Because you're using the methods of the class, you don't really need to know about the internals of the class and thus you're not likely to screw anything up.

[mmj_ngen]

Porfiry2001 wrote:

The limitation is that you cannot add instance variables -- only methods.

Yeah, I realized that. You have a good point about the likelihood of screwing anything up. But the chance is still there. Am I correct in assuming that the methods can still screw with private instance variables? So, if for some extremely strange reason the names of the instance variables were leaked in a public forum, then the class is compromised.

So, a class would be protected from misuse by a third party through anonymity (they don't necessarily know what the can screw with), and from potentially incompetent co- workers, which I myself may be one , through concession. I have a tendency towards paranoia…it's just that if there is a way to screw something up, someone always seems to find it.

I guess the benefits of categories outweigh the potential problems, but I'm still a bit uncomfortable with the potential freedom. Thanks for the good information, though. I think I'll start experimenting with them a little.

[Porfiry2001]

But the chance is still there. Am I correct in assuming that the methods can still screw with private instance variables? So, if for some extremely strange reason the names of the instance variables were leaked in a public forum, then the class is compromised.

I'm not sure how the class would be 'compromised'. It's not as if it's hiding any great secrets. If you program against the non-public API and the instance variables of a class, then you are an idiot (or you are painfully aware that you're standing on solid foundation of nothing (maybe Jello) and know not to complain when your app stops working). It is your program that will break.

The other protection here (as least in Cocoa) is that many major classes (I think I mentioned this already) are abstract class clusters , and so there are no instance variables to get your hands into. You can't get at the private subclasses that actually have the instance variables and the real implementation. This is probably a valuable design pattern if you suspect your fellow programmers are unable to understand OOP and modularity.

So, a class would be protected from misuse by a third party through anonymity (they don't necessarily know what the can screw with), and from potentially incompetent co- workers, which I myself may be one
, through concession. I have a tendency towards paranoia…it's just that if there is a way to screw something up, someone always seems to find it.

There is no language that will make you a good programmer. Likewise, there is no language that will keep you from hurting yourself. The only way to deal with that is using a straight-jacket.

I guess the benefits of categories outweigh the potential problems, but I'm still a bit uncomfortable with the potential freedom. Thanks for the good information, though. I think I'll start experimenting with them a little.

It's no more dangerous that letting someone dereference a pointer at a random location or running an infinite loop If you wish to protect yourself from stupidity, wear a helmet and try not to move around too much because there's a lot of pointy things in the world you could fall on.

[mmj_ngen]

lol. Don't stick me on the short bus with the special folk yet. I'm just cautious.

Porifiry2001 wrote:

If you program against the non-public API and the instance
variables of a class, then you are an idiot

I agree. Unfortunately, when more developers are working on a project, then there is a greater chance for less thoughtful developers. Also, I was wondering about classes that were going to be used by third party development as well, but I think you answered that in the next paragraph.

The other protection here (as least in Cocoa) is that many major
classes (I think I mentioned this already) are abstract class clusters, and so there are no instance variables to get your hands into. You can't get at the private subclasses that actually have the instance variables and the real implementation.

I don't recall reading that previously in your posts. That's a good idea though. I didn't read much about class clusters in Cocoa yet. I'm still very much green when it comes to Cocoa. I think that answers a lot of my questions though. That's a really good idea. Thanks.

There is no language that will make you a good programmer. Likewise, there is no language that will keep you from hurting yourself...

Damn. There something you don't learn in school. I was hoping to find one that would wipe my ass as well.

If you wish to protect yourself from stupidity, wear a helmet and try not to move around too much…

Does it work for forum posts as well? . I think you may be reading way too much into my questions, but I appreciate the responses.

Thanks again for the class clusters suggestion.

[Porfiry2001]

Glad to help.

Here's a useful doc from Apple describing class clusters in more detail:

http://developer.apple.com/techpubs/...ssClusters.pdf