Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > Why is Cocoa so confusing?

Why is Cocoa so confusing?
Thread Tools
macgyvr64
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Nov 6, 2003, 09:06 PM
 
I've tried several times to learn Cocoa, and it's simply beyond me. I've bought three boks on it (Cocoa for Dummies, Learning Cocoa, and Cocoa Programming for Mac OS X) and followede examples in them, but I find myself not being able to *do* anything outside of them. I'm pretty good with C/C++ and PHP, but the synatx and general flow of Cocoa is baffling to me. I know several Cocoa programmers who say they love it, but I can't figure it out. Am I missing something that others find screamingly obvious?
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Nov 6, 2003, 09:31 PM
 
I had similar problems at first. It takes some time to get into the right mind-set if you're not used to thinking in "their" way already. However, if you can get over the hurdle, and get used to it, it is very easy to use.

The most difficult thing is not the language, but the sets of APIs. There are so many classes with so many methods!

But the documentation is good - once you get used to it.

Some of the tutorials at cocoa dev central are good.
     
Catfish_Man
Mac Elite
Join Date: Aug 2001
Status: Offline
Reply With Quote
Nov 6, 2003, 11:19 PM
 
Originally posted by Brass:
I had similar problems at first. It takes some time to get into the right mind-set if you're not used to thinking in "their" way already. However, if you can get over the hurdle, and get used to it, it is very easy to use.

The most difficult thing is not the language, but the sets of APIs. There are so many classes with so many methods!

But the documentation is good - once you get used to it.

Some of the tutorials at cocoa dev central are good.
So many methods I'll agree with, but the number of classes in Cocoa is NOTHING compared to Java.

To the original poster: What have you been trying to do?
     
K++
Senior User
Join Date: Jan 2002
Location: NYC
Status: Offline
Reply With Quote
Nov 7, 2003, 01:59 AM
 
Cocoa is not hard, the thing is that it is a REAL programming language that hard core enforces Model View Controller. A solid understanding of C is required and knowledge of Object Oriented design is a must.

Learn Java, or attempt to do so. As soon as you do you will learn the greatness of Cocoa.
( Last edited by K++; Nov 7, 2003 at 03:14 AM. )
     
macaroni
Fresh-Faced Recruit
Join Date: Dec 2002
Status: Offline
Reply With Quote
Nov 17, 2003, 01:25 PM
 
It certainly takes a while to get comfortable with Cocoa.

What I found helpful after I do the tutorials in the book is to reread the chapters without actually coding. This allows me to then concentrate on the concepts that they are trying to enforce.
After each tutorial chapter, I always try to create simple and similar apps of my own and using their code as guides.

Honestly I wish I could go faster in my learning process but that is the way I just learn.

At first I thought I needed to learn everything at once but then I realized that I just needed to learn the core essentials and the other bells and whistles I will just have to learn when needed.





Originally posted by macgyvr64:
I've tried several times to learn Cocoa, and it's simply beyond me. I've bought three boks on it (Cocoa for Dummies, Learning Cocoa, and Cocoa Programming for Mac OS X) and followede examples in them, but I find myself not being able to *do* anything outside of them. I'm pretty good with C/C++ and PHP, but the synatx and general flow of Cocoa is baffling to me. I know several Cocoa programmers who say they love it, but I can't figure it out. Am I missing something that others find screamingly obvious?
     
wadesworld
Grizzled Veteran
Join Date: Apr 2001
Status: Offline
Reply With Quote
Nov 18, 2003, 01:24 AM
 
The hardest thing to learn about Cocoa is that if you can't figure out a way to code it, there's probably a mind-boggling simple way you're missing.

That's always been my problem - I spend hours trying to find a traditional solution to a problem, only to learn "Oh - I just assign this to the delegate...click...click...5 lines of code...done."

Cocoa does require a different way of thinking which is usually, "If it seems too hard, you're probably doing it wrong."

It obviously takes some time to learn the tricks and to adjust your mind to the Cocoa way of thinking, but it's a joy to use.

Wade
     
iJed
Dedicated MacNNer
Join Date: May 2001
Location: Edinburgh, UK
Status: Offline
Reply With Quote
Nov 18, 2003, 06:22 PM
 
Its simply a matter of learning object oriented programming first. If you can do this and are quite proficient at it then you should be able to pick up Cocoa reasonably quickly. It still has a few concepts that you will need to learn but these are not difficult once you know the basics.
     
juanpacolopez
Dedicated MacNNer
Join Date: May 2003
Location: Atlanta, GA
Status: Offline
Reply With Quote
Nov 19, 2003, 04:42 PM
 
Originally posted by wadesworld:
The hardest thing to learn about Cocoa is that if you can't figure out a way to code it, there's probably a mind-boggling simple way you're missing.

That's always been my problem - I spend hours trying to find a traditional solution to a problem, only to learn "Oh - I just assign this to the delegate...click...click...5 lines of code...done."

Cocoa does require a different way of thinking which is usually, "If it seems too hard, you're probably doing it wrong."

It obviously takes some time to learn the tricks and to adjust your mind to the Cocoa way of thinking, but it's a joy to use.

Wade
I second this. Before I delved into Cocoa for the first time I was a hardcore Java developer...

One thing I learned is that if something seems too hard in Java, it IS too hard.

You're absolutely right about Cocoa having a "better way". I can't count the amount of time I spent trying to make some interface thing work for literally HOURS, only to find out that there's a delegate method to do exactly what I want that take 30 seconds.
Alex

G7 Software: home Tetrinet Aqua
-----
"Utopia" 1Ghz TiBook SuperDrive w/ 1Gb RAM.
     
macgyvr64  (op)
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Nov 19, 2003, 04:47 PM
 
Yeah, I must be missing something, then. I think I'm going to learn a little Java first...
     
jewelskull
Fresh-Faced Recruit
Join Date: Jul 2002
Location: San Jose, CA, USA
Status: Offline
Reply With Quote
Nov 19, 2003, 06:00 PM
 
Originally posted by iJed:
Its simply a matter of learning object oriented programming first. If you can do this and are quite proficient at it then you should be able to pick up Cocoa reasonably quickly. It still has a few concepts that you will need to learn but these are not difficult once you know the basics.
I'd say understanding object oriented design and, more importantly, model-view-controller design.

I've done MVC style UI work before with other toolkits. Seeing that Cocoa is very well designed, it literally took me a day to learn all the basics of Cocoa, in addition to dealing with it all in Java, and only using the docs on Apple's dev site.

As soon as you see the MVC pattern you can draw on all that past experience. So look at as paying your dues now for MVC and UI design work later on. Next time around it will go much faster.
     
bousozoku
Forum Regular
Join Date: May 2001
Location: Oviedo, Floriduh USA
Status: Offline
Reply With Quote
Dec 10, 2003, 01:07 AM
 
Probably the hardest thing to do is to unlearn C++.

Objective-C wants you to leave as much to runtime as possible and C++ is the opposite. It's much easier to go from Java to Objective-C than it is to go from C++.

The Apple documentation is still poor after 4 years of Mac OS X but O'Reilly just published Cocoa in a Nutshell, so that should help a lot of people. The Java in a Nutshell book is my favourite for that language.
folding@home is good for you.
     
macgyvr64  (op)
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Dec 10, 2003, 01:19 AM
 
That O'Reilly book sounds good..
( Last edited by macgyvr64; Feb 12, 2004 at 05:19 PM. )
     
nufferkay
Fresh-Faced Recruit
Join Date: Dec 2003
Status: Offline
Reply With Quote
Dec 10, 2003, 02:29 AM
 
I also come from a C/PHP background. The biggest problem I've found is that the documentation can be so confusing.

For instance, when I started out on the app I'm working on as a learning project, it took me an hour to figure out how to set the contents of an NSTextView.

Turns out there's a setString: method, but it must have been buried in three or four levels of inheritance in the documentation, because I just couldn't find a method anywhere to set the value. All of Apple's example projects subclassed and overrode methods to death - I couldn't make heads or tails of them.

Finally I pulled out an old online tutorial I hadn't looked at in months, and there it was staring me in the face.

For this reason, I've found that a good book, a bunch of online tutorials, and Google are the best way to learn something like this. You really just need something you can go back to again and again for examples - of structure, of procedure, of conventions, and simply the method and variable names that you need to know.

I really like the book I have: Cocoa Programming for Mac OS X, by Aaron Hillegass (and no, I am in no way affiliated with anyone having anything to do with the book, I just find it very useful). In particular, I found the explanations of Model-View-Controller, delegate methods and memory management were nice and clear. It misses a few things (such as the darned setString: method mentioned above), but more b/c it can't cover every detail of every class if it's going to explain the concepts thoroughly. I also liked that there's an online message board where people discuss how they solved the "challenge" assignments that are at the end of most chapters - it gives you an insight into different ways to solve problems.

And a google for "cocoa" and whatever is giving you problems will often come up with some useful info.
     
Turias
Mac Elite
Join Date: Nov 2003
Location: Minnesota
Status: Offline
Reply With Quote
Dec 10, 2003, 04:07 PM
 
Originally posted by macgyvr64:
Ooh, that O'Reilly book soudns good..
It's a good book if you basically want a printed version of the documentation. It's great if you want to look up methods and classes quickly, but if you want to actually learn Cocoa, I would go with Cocoa Programming for Mac OS X, by Aaron Hillegass
     
davecom
Mac Elite
Join Date: Jan 2001
Location: New York
Status: Offline
Reply With Quote
Dec 10, 2003, 05:13 PM
 
If you seriously think Cocoa is overly complex PLEASE check out most C++ frameworks, C libraries, etc. This is about as easy as 'real' GUI programming gets. I would recommend some books on object oriented programming.
     
bousozoku
Forum Regular
Join Date: May 2001
Location: Oviedo, Floriduh USA
Status: Offline
Reply With Quote
Dec 11, 2003, 12:42 AM
 
Originally posted by davecom:
If you seriously think Cocoa is overly complex PLEASE check out most C++ frameworks, C libraries, etc. This is about as easy as 'real' GUI programming gets. I would recommend some books on object oriented programming.
If you've used Borland's Object Windows Library, I think you'd find that it was the C++ application framework exception. It was designed with a Smalltalk flavour. It's unfortunate that it never made it to Macintosh.
folding@home is good for you.
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 11, 2003, 05:03 PM
 
I'd like to add a different perspective...

I can't get over the syntax.

I've tried about a dozen times, tried going through tutorials, and the whole syntactical structure baffles me. I'm very much a C++ person (and love Java, except for the bytecode performance penalties), so I like parenthesies, dots, etc. The square brackets lose me. Even moreso, I could not discern when named variables are used, when they aren't, etc.

If anyone knows a good starting tutorial for the basics of the language and syntax (nevermind API's - I can soak up API's fairly easily), I'd appreciate it. I've really missed Mac programming over the years (and I don't see the point in using Carbon given my affinity for object oriented design).
     
nufferkay
Fresh-Faced Recruit
Join Date: Dec 2003
Status: Offline
Reply With Quote
Dec 11, 2003, 06:50 PM
 
This tutorial is pretty good at explaining Obj-C syntax for those who are accustomed to other OOP languages:

http://www.macdevcenter.com/pub/a/ma...oa.html?page=2

The introductions in Apple's developer documentation aren't bad either.
     
hayesk
Guest
Status:
Reply With Quote
Dec 12, 2003, 01:52 PM
 
Originally posted by macgyvr64:
I've tried several times to learn Cocoa, and it's simply beyond me. I've bought three boks on it (Cocoa for Dummies, Learning Cocoa, and Cocoa Programming for Mac OS X) and followede examples in them, but I find myself not being able to *do* anything outside of them. I'm pretty good with C/C++ and PHP, but the synatx and general flow of Cocoa is baffling to me. I know several Cocoa programmers who say they love it, but I can't figure it out. Am I missing something that others find screamingly obvious?
"Cocoa Programming for Mac OS X" is an excellent book. Have you actually read the book or just did the examples? If you read through everything then it becomes clear. Make sure you do the challenges at the end of each chapter - they helped me a lot. If you get stuck at the challenges, the web site for the book helps out a lot. But try to do them on your own first.

Cocoa was confusing for me at first, but it gradually became more familiar. My previous expertise was C, C++, and the PowerPlant framework in CodeWarrior.
     
macgyvr64  (op)
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Dec 12, 2003, 03:12 PM
 
What I really need is motivation, I think... I just mess with it on and off..
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 12, 2003, 05:48 PM
 
Originally posted by nufferkay:
This tutorial is pretty good at explaining Obj-C syntax for those who are accustomed to other OOP languages:

http://www.macdevcenter.com/pub/a/ma...oa.html?page=2

The introductions in Apple's developer documentation aren't bad either.
This is actually one of the tutorials that confuses me. I get pages 1 and 2 - pretty straightforward. However, this confuses me:
- (void)setXLocation:(double)x yLocation:(double)y

So, does this equal the:

void setXLocation (double x, double y);

of C++? If so, why is there an X and a Y being passed for something called "setXLocation"? Why is "yLocation" named, and does it have to be?

This is where I get into confusion with named parameters, unnamed ones, what exactly are the parameters versus the member name, etc.

Any help for a poor lost soul? I really would like to use Cocoa - I love the underlying API design.
( Last edited by diamondsw; Dec 12, 2003 at 06:01 PM. )
     
K++
Senior User
Join Date: Jan 2002
Location: NYC
Status: Offline
Reply With Quote
Dec 12, 2003, 07:17 PM
 
Originally posted by diamondsw:
This is actually one of the tutorials that confuses me. I get pages 1 and 2 - pretty straightforward. However, this confuses me:
- (void)setXLocation:(double)x yLocation:(double)y

So, does this equal the:

void setXLocation (double x, double y);

of C++? If so, why is there an X and a Y being passed for something called "setXLocation"? Why is "yLocation" named, and does it have to be?

This is where I get into confusion with named parameters, unnamed ones, what exactly are the parameters versus the member name, etc.

Any help for a poor lost soul? I really would like to use Cocoa - I love the underlying API design.
They are functionally equivalent however the goal of named parameters has always been readability.

setLocation( double x, double y ) is fairly straight forward, but what about when your using that Location later on in a setObjectAtLocation( double width, double height, double x, double y );

compare these two:

Code:
//prototype/decleration - (void)setObject:(NSObject)obj withHeight:(double)height withWidth:(double)width atLocationWithX:(double)x andYAt:(double)y { [self makeDrawingAreaWithHeight:height andWidth:width]; [self drawInArea: obj]; [self drawAreaAtX:x withY:y]; } //use [NSPicture setObject:obj withHeight:a withWidth:b atLocationWithX:x andYAt:y];
Code:
//declaration void setObject( Object obj, double height, double width, double x, double y ) { this.makeDrawingAreaWithSize( height,width ); this.drawInArea( obj ); this.drawAreaAt( x, y ); } //use MyPicure.setObject( obj, a, b, x, y ); );
At first glance the C++ code looks both simpler and cleaner. but if you look closer you notice that when using the method you have defined things are alot easier when your using the method since namedParemeters serve to show exactly what goes where without having to reference the method signature.

Basically the only thing harder is writing the method signature in the first place because it seems convoluted, and inside the method is the same as your plain C++ method, variables are handled the same, but again only when using your method do you see the value of namedParemeters.

P.S. not sure I touched on it, but Parameters need to be named except for the case of variable parameter methods.
     
nufferkay
Fresh-Faced Recruit
Join Date: Dec 2003
Status: Offline
Reply With Quote
Dec 13, 2003, 01:49 AM
 
Originally posted by diamondsw:
However, this confuses me:
- (void)setXLocation:(double)x yLocation:(double)y

So, does this equal the:

void setXLocation (double x, double y);

of C++? <snip>
Yes, it's the same thing. The way Obj-C works is that a function that takes parameters has a colon preceding each parameter, and the words proceding the colon should describe the parameter. Perhaps the setXlocation:YLocation: function is confusingly named - but then how else would you name it? ;-) I suppose it works best for functions that take one, I guess "central" parameter and others that modify how the function works with the first one.

Anyhow, the naming convention is especially useful for functions that take a long list of parameters (you'll often see the function declarations with each parameter on a new line and the colons aligned, as follows [adapted from Apple's documentation for the NSWindow class]):

Code:
- (void)dragImage:(NSImage *)anImage at:(NSPoint)aPoint offset:(NSSize)initialOffset event:(NSEvent *)theEvent pasteboard:(NSPasteboard *)pboard source:(id)sourceObject slideBack:(BOOL)slideBack Begins a dragging session.... <snip>
Does that make sense?
-N
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 14, 2003, 06:41 PM
 
Still, above can you not use this:

- (void)setLocation xLocation: (double)x yLocation: (double)y

Or does the first parameter have to be named with the member's name? It just seems very odd to me - I read the original prototype as having a member called "setXLocation", with an unnamed first parameter, and a named "yLocation" second parameter.

If the first parameter always must have the same name as the member function, then I find that really annoying.

(BTW, I fully understand the benefits of named parameters, and on complex functions I've dearly wished they were more widespread. I just don't know that I like requiring the first parameter to be the same name as the function.)

Finally, why did the designers of Objective C seem to make up new syntax for its own sake? Since it was based on C, I don't see why they needed to significantly revamp the syntax (square brackets, function signatures, @interface directives, etc). Java is (to me) a good example of creating a very streamlined and consistent OO language without throwing out the C/C++ syntax heritage. As a result, I can shift from reading C, C++, and Java code with relative ease. After all, the vast majority of code these days is a lot of accessing member functions/variables, and the usual grunt work of if/then/else, for/next, etc, and all of this is consistent syntax-wise between the languages. Sometimes you have to invent new syntax (templating, for example), but why significantly redesign things that already exist and work? For instance, why could the above not have been something like:

void setLocation (xLocation:double x, yLocation:double y);

Thanks for helping me get through this mental block of mine.
     
nufferkay
Fresh-Faced Recruit
Join Date: Dec 2003
Status: Offline
Reply With Quote
Dec 14, 2003, 06:56 PM
 
Originally posted by diamondsw:
Still, above can you not use this:

- (void)setLocation xLocation: (double)x yLocation: (double)y

Or does the first parameter have to be named with the member's name?

Finally, why did the designers of Objective C seem to make up new syntax for its own sake?
No, in Obj-C the function name has to be attached to the first parameter name. Why? I don't really know, but I'm guessing with the space it would probably be much harder for the compiler to parse - and it also helps identify the function as a single entity. Or maybe it's just arbitrary

Perhaps the function would have been better named setLocationWithXLocation:andYLocation: - would that make more sense to you?

[Edit] BTW, it's helpful to read the function name as one phrase - setXLocation:YLocation:, or for another example (an NSDictionary method) initWithObjects:forKeys:count: [/Edit]

Anyhow, from what I gather, the syntax is not completely new, but based on Smalltalk. Apparently, the language was inspired as a way to merge the low-level power of C with the less strongly typed OOP features of Smalltalk that permit a lot of runtime flexibility.
( Last edited by nufferkay; Dec 14, 2003 at 07:03 PM. )
     
K++
Senior User
Join Date: Jan 2002
Location: NYC
Status: Offline
Reply With Quote
Dec 14, 2003, 10:26 PM
 
Originally posted by diamondsw:
Still, above can you not use this:

- (void)setLocation xLocation: (double)x yLocation: (double)y

Or does the first parameter have to be named with the member's name? It just seems very odd to me - I read the original prototype as having a member called "setXLocation", with an unnamed first parameter, and a named "yLocation" second parameter.

If the first parameter always must have the same name as the member function, then I find that really annoying. :(

(BTW, I fully understand the benefits of named parameters, and on complex functions I've dearly wished they were more widespread. I just don't know that I like requiring the first parameter to be the same name as the function.)

You would do well to actually read through the books on Cocoa because the "name" of the function is not seperate from its parameters. The example you made up is not valid.
A valid one is
- (void) setLocationAtX:(double)x andY:(double)y;

In that case the methods name is setLocationAtX:andY;
The colons are part of the methods name. Every Cocoa book mentions this when they cover messages and selectors and reiterates it when covering methods of classes. At least every Cocoa book I ever read did. Apple's docs also point this out.



Finally, why did the designers of Objective C seem to make up new syntax for its own sake? Since it was based on C, I don't see why they needed to significantly revamp the syntax (square brackets, function signatures, @interface directives, etc). Java is (to me) a good example of creating a very streamlined and consistent OO language without throwing out the C/C++ syntax heritage. As a result, I can shift from reading C, C++, and Java code with relative ease. After all, the vast majority of code these days is a lot of accessing member functions/variables, and the usual grunt work of if/then/else, for/next, etc, and all of this is consistent syntax-wise between the languages. Sometimes you have to invent new syntax (templating, for example), but why significantly redesign things that already exist and work? For instance, why could the above not have been something like:

void setLocation (xLocation:double x, yLocation:double y);
NO! Objective C is a superset of C, which means that all C is valid inside of it not the other way around. C's heritage is actually SmallTalk which is where the syntax comes from. The primary reason for the different syntax for classes and messages to objects is because the creator of the SmallTalk and Objective C languages abhored the fact that C++'s objects seemed hacked in and its syntax too similar to C's structs to make it obvious that classes are VERY different from structs. That and by making it similiar to C you would be even more confused than you are now since that example to me looks awful.
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 15, 2003, 02:38 AM
 
Originally posted by K++:
You would do well to actually read through the books on Cocoa because the "name" of the function is not seperate from its parameters. The example you made up is not valid.
A valid one is
- (void) setLocationAtX: (double)x andY: (double)y;

In that case the methods name is setLocationAtX:andY;
The colons are part of the methods name. Every Cocoa book mentions this when they cover messages and selectors and reiterates it when covering methods of classes. At least every Cocoa book I ever read did. Apple's docs also point this out.
I must not have been clear in my post. At that point I was only asking why the syntax would not have been designed in such a way - I wasn't saying it would work. I *still* don't see why the method name should include all of the parameters as the "name". I suppose it could be argued this is part of an expanded function signature, but it's strange. Coming from a background of (in order) BASIC (gotta start somewhere), C, C++, Java, Scheme, Lisp, and Visual Basic, I just don't think I've seen anything like that before, so it's been confusing me. I understand what the syntax means, I just don't understand why the syntax was designed in such a way.

Originally posted by K++:
NO! Objective C is a superset of C, which means that all C is valid inside of it not the other way around. C's heritage is actually SmallTalk which is where the syntax comes from. The primary reason for the different syntax for classes and messages to objects is because the creator of the SmallTalk and Objective C languages abhored the fact that C++'s objects seemed hacked in and its syntax too similar to C's structs to make it obvious that classes are VERY different from structs. That and by making it similiar to C you would be even more confused than you are now since that example to me looks awful.
Again, I must not have been clear. I never intended to say you could write the code in such a fashion, I merely wondered why Objective-C decided to do away with that style of syntax and adopt its own variant. I would hope that I've at least made it clear that I know that Objective-C is a superset of C. If not, I really worry about my writing style.

As for better, worse, etc, I personally feel that the consistency of syntax aids in picking up and quickly being able to learn a language. If you know C/C++, you can pick up some pages of Java code, and apart from some new keywords, follow the gist of what's going on. However, there's nothing to prepare to to read "aCircle = [[Circle alloc] init];". The difference in syntax adopted by Objective-C puts up an artificial barrier to learning the actual language, and I have yet to see why it's useful (I suppose if I knew SmallTalk, this wouldn't be such a big deal or might make more sense).

I'm certainly no expert at language design, but I rather doubt that syntax differences would help you understand object oriented programming. It's a mental leap, and not one that I see syntax helping. However, by adopting such a different syntax within what is otherwise a familiar language, it just seems to add more to learn (unneccessarily), more to remember, and more mistakes to make.

*sigh* I REALLY want to be able to use Cocoa and the NS API's. I REALLY adore object oriented design and appreciate elegance. However, the syntax of the language still bugs the heck out of me - it seems to make a lot of things different for the sake of being different, not to solve any problem. Named parameters are a good example - this is a genuine benefit to the language and very useful, but why is the name of the function/method tied to the first parameter? I just see that as an ongoing nuisance, spawning strangely named functions and parameters. Or "import" - why not just have the compiler be more smart about "include" when it sees it's compiling Objective-C code - why the new keyword?

How about a couple real newbie questions (and I'll preface this by saying I have not looked into this in a year or more):

1) If I used Java instead of Objective-C, will I still be running through bytecode with its associated performance hit, or will it be compiled native?
2) Are there any major limitations to using Cocoa from Java?
3) Has Apple provided decent reference material for learning Cocoa from a Java point of view? Last I checked (quite a while ago) I found extraordinarily little on the subject.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Dec 15, 2003, 05:17 AM
 
Originally posted by diamondsw:
I understand what the syntax means, I just don't understand why the syntax was designed in such a way.
It comes from Smalltalk (the granddaddy of OOP), where the philosophy is that you do not call functions on data, you send messages to objects. This is a fundamental principle behind both Smalltalk and Objective-C.

Originally posted by diamondsw:
I'm certainly no expert at language design, but I rather doubt that syntax differences would help you understand object oriented programming. It's a mental leap, and not one that I see syntax helping. However, by adopting such a different syntax within what is otherwise a familiar language, it just seems to add more to learn (unneccessarily), more to remember, and more mistakes to make.
The syntax really shouldn't be that difficult. I think it took me seriously one day to get past the differences in syntax. That's less time than it took me to pick up the quirks of C++ syntax.

Originally posted by diamondsw:
Named parameters are a good example - this is a genuine benefit to the language and very useful, but why is the name of the function/method tied to the first parameter? I just see that as an ongoing nuisance, spawning strangely named functions and parameters. Or "import" - why not just have the compiler be more smart about "include" when it sees it's compiling Objective-C code - why the new keyword?
Named parameters: The method name is all stored as a single string with no spaces (AFAIK). The compiler just knows to look at colons as dividers where parameters go. Just imagine there is a space before each capital letter -- that's how it's intended to be read.
Import: I am not sure here, but it seems to me that since Objective-C is a true superset of C, they aren't allowed to change the behavior of any C directives. (Also: Java uses "import" as well.)
( Last edited by Chuckit; Dec 15, 2003 at 06:26 AM. )
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
michaelb
Mac Elite
Join Date: Oct 2000
Location: Australia
Status: Offline
Reply With Quote
Dec 15, 2003, 06:03 AM
 
Originally posted by diamondsw:
As for better, worse, etc, I personally feel that the consistency of syntax aids in picking up and quickly being able to learn a language. If you know C/C++, you can pick up some pages of Java code, and apart from some new keywords, follow the gist of what's going on.
However, there's nothing to prepare to to read "aCircle = [[Circle alloc] init];".
Which might need to be

aCircle = [[[Circle alloc] init] autorelease];

anyway! (No automatic garbage collection in Objective-C.)

You make valid points, and it's certainly possible the Objective-C userbase would be higher if it was closer to the stylistic conventions of other popular languages, but saving a programmer the 10 mins it takes to learn the [] conventions shouldn't necessarily have influenced the elegant design of a very powerful concept.

Messaging is an intrinsic part of Objective-C and is what allows it to be so dynamic. There are only a few symbols added to the C language to allow this, and once learnt, they're learnt. It takes far longer to learn the framework than it does the language.

Also, historically, when Objective-C (mid 1980s) was designed, C++ (early 1980s) didn't have nearly the following and familiarity it does now, and Java wasn't even on the drawing board. So it's just a historical "accident" that C++ / Java syntax looks familiar where Objective-C's C extensions don't.


To answer your using Java instead of Objective-C for Cocoa questions:

Originally posted by diamondsw:
1) If I used Java instead of Objective-C, will I still be running through bytecode with its associated performance hit, or will it be compiled native?
You're running through the Java Virtual Machine which slows application startup and consumes resources. The bridge to the actual Cocoa frameworks should be just as efficient though. So, it depends on how snappy you need your core code to be.

Originally posted by diamondsw:
2) Are there any major limitations to using Cocoa from Java?
Yes... IMO. If you're doing it to avoid learning Objective-C, all the good sample code is written in Objective-C so you may miss important stuff. Cocoa itself is written in Objective-C.

You'd really be calling into Cocoa like a visitor to a country uses a foreign language, it may do the job but doesn't really get into the culture of the place.


Originally posted by diamondsw:
3) Has Apple provided decent reference material for learning Cocoa from a Java point of view? Last I checked (quite a while ago) I found extraordinarily little on the subject.
Check it out: http://developer.apple.com/documenta...Java-date.html

Apple's emphasis is mostly on letting proficient Java developers with a large codebase of Java code easily turn it into Mac OS X apps. Xcode comes with a Java documentation category.


However, as a way of getting the most out of both Cocoa and Mac OS X, I think most developers would argue that learning Objective-C is the best route.

It's really not that hard once you get past the [square] brackets, the fully named: method: parameters, and the @ signs!


.
( Last edited by michaelb; Dec 15, 2003 at 06:13 AM. )
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 15, 2003, 01:43 PM
 
Originally posted by michaelb:
It's really not that hard once you get past the [square] brackets, the fully named: method: parameters, and the @ signs!
Yes, that about sums it up.

I'll try taking another crack at it over Christmas when I have some actual time. Thanks for taking the time to help and discuss!
     
macgyvr64  (op)
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Dec 15, 2003, 05:24 PM
 
Ditto :-P
     
skyman
Mac Elite
Join Date: Mar 2000
Location: Utah, USA
Status: Offline
Reply With Quote
Dec 19, 2003, 01:34 AM
 
Ok, I am up to speed on C++ but Object C is a bear for me.

I can do the basic C++ stuff in Cocoa but when it comes to Object C I am lost.

Can anyone suggest a good book(s) or on line reference for learning OOP?

Something for the OOP challenged

Thanks
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Dec 19, 2003, 11:01 AM
 
I just want to add that I was also motherlessly confused with named parameters in the beginning and the exception of the first parameter having no seperate name. I think this is a definite problem with Obj-C design because I assume that many have run into exactly this problem (On the other hand I had no problems with the @ syntax). What really helped me more than any other documentation was O'Reilly's Obj-C in a Nutshell.

The book is simple, to the point and easy to follow. The basic syntax, the parts which seem to confuse a lot of newbies, is covered line by line. FWIW, one of Obj-C's great strengths, apart from its loose typing, IMO, is the fact that it integrates so well with both C and C++.
weird wabbit
     
PBG4 User
Senior User
Join Date: Feb 2001
Location: Deer Crossing, CT
Status: Offline
Reply With Quote
Dec 19, 2003, 11:21 AM
 
I just wanted to point out there is a .pdf book installed with the Developer Tools that covers Obj-C completely. It goes over Model-View-Controller design and the Obj-C syntax. It is definitely worth a read and is a full size book (which can be ordered in dead-tree form) not some 15 page pamphlet. Definitely poke around in the /Developer directory tree. There's some good stuff in there that isn't easily found unless you surf through the directories.
20" iMac G5! :D AND MacBook 1.83GHz!
Canon Digital Rebel Kit + 75 - 300mm lens. Yum Yum! :D
Check out my OS X Musical Scales program
     
skyman
Mac Elite
Join Date: Mar 2000
Location: Utah, USA
Status: Offline
Reply With Quote
Dec 19, 2003, 06:25 PM
 
Originally posted by PBG4 User:
I just wanted to point out there is a .pdf book installed with the Developer Tools that covers Obj-C completely. It goes over Model-View-Controller design and the Obj-C syntax. It is definitely worth a read and is a full size book (which can be ordered in dead-tree form) not some 15 page pamphlet. Definitely poke around in the /Developer directory tree. There's some good stuff in there that isn't easily found unless you surf through the directories.
Thanks I will take a look...

I just hope I can find a laymans example / explaination of OOP.

I really like programming but OOP is a bear.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Dec 19, 2003, 08:35 PM
 
Originally posted by skyman:
I just hope I can find a laymans example / explaination of OOP.

I really like programming but OOP is a bear.
I think Sun's OOP introduction is pretty good. It's focused on Java rather than Objective-C, but the differences aren't that big. It seems a bit more beginner-friendly than Apple's.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
skyman
Mac Elite
Join Date: Mar 2000
Location: Utah, USA
Status: Offline
Reply With Quote
Dec 20, 2003, 12:42 AM
 
Originally posted by Chuckit:
I think Sun's OOP introduction is pretty good. It's focused on Java rather than Objective-C, but the differences aren't that big. It seems a bit more beginner-friendly than Apple's.
WOW. This is indeed a very good tutorial. I am actually beginning to understand OOP!!!

Thanks.
     
Catfish_Man
Mac Elite
Join Date: Aug 2001
Status: Offline
Reply With Quote
Dec 20, 2003, 02:00 AM
 
Originally posted by skyman:
WOW. This is indeed a very good tutorial. I am actually beginning to understand OOP!!!

Thanks.
Excellent. It makes a tremendous amount of sense once you're used to it, but I remember struggling to figure out why on earth anyone would use it, and how to use it effectively.
     
hayesk
Guest
Status:
Reply With Quote
Dec 22, 2003, 11:17 AM
 
Originally posted by diamondsw:
Still, above can you not use this:

- (void)setLocation xLocation: (double)x yLocation: (double)y

Or does the first parameter have to be named with the member's name? It just seems very odd to me - I read the original prototype as having a member called "setXLocation", with an unnamed first parameter, and a named "yLocation" second parameter.

If the first parameter always must have the same name as the member function, then I find that really annoying. :(
The problem is you are thinking that the name of the method is "setXLocation". It isn't. The name is setXLocation:yLocation." It's the whole thing - you put the parameters where they fit.

In a real world example. Let's say I want you to go to the supermarket to get groceries. In Objective-C the prototype would be
goToStore:(store *)s andBuy:(grocery *)g

I would say "You, go to the A&P and buy milk." or in Obj-C:
[you goToStore:AandP andBuy:milk].

In Java (or another OOP language) it would be:
you.goToStoreAndBuy(AandP,milk);
which translate to (You, go to store and buy A&P, milk) - which makes no sense whatsoever.

When you start to think of it that way (in real english terms), Obj-C becomes much more readable and easier to write methods. So much, that I really had to stop and think about how to do the Java version. Obj-C feels much more natural.
     
diamondsw
Senior User
Join Date: Apr 2000
Location: Woodridge, IL
Status: Offline
Reply With Quote
Dec 31, 2003, 01:02 PM
 
Originally posted by hayesk:
The problem is you are thinking that the name of the method is "setXLocation". It isn't. The name is setXLocation:yLocation." It's the whole thing - you put the parameters where they fit.

In a real world example. Let's say I want you to go to the supermarket to get groceries. In Objective-C the prototype would be
goToStorestore *)s andBuygrocery *)g

I would say "You, go to the A&P and buy milk." or in Obj-C:
[you goToStore:AandP andBuy:milk].

In Java (or another OOP language) it would be:
you.goToStoreAndBuy(AandP,milk);
which translate to (You, go to store and buy A&P, milk) - which makes no sense whatsoever.

When you start to think of it that way (in real english terms), Obj-C becomes much more readable and easier to write methods. So much, that I really had to stop and think about how to do the Java version. Obj-C feels much more natural.
What I'm getting at is that "setXLocation:YLocation" just seems wrong. You're setting a location, that happens to be two-dimensional.

In any other language I've seem (except Objective-C/SmallTalk), this would be setLocation(x as double, y as double) in whatever syntax the language used. The action ("setLocation") is kept distinct from the object of that action ("x" and "y"). Instead of the usual action(object, object) paradigm, Objective-C uses actionObject:Object. All I'm saying is there does not appear to be any good reason to merge the two concepts and create "actionObject".

What can I say - maybe I'll get it at some point. Right now it seems to needlessly mix together concepts in a thoroughly unhelpful way.
     
calumr
Forum Regular
Join Date: Sep 2000
Location: UK
Status: Offline
Reply With Quote
Jan 1, 2004, 12:40 PM
 
Originally posted by diamondsw:
What can I say - maybe I'll get it at some point. Right now it seems to needlessly mix together concepts in a thoroughly unhelpful way.
Imagine a C function that swaps 2 views:

Code:
ReplaceSubview(view1, view2)
And tell me which view is added and which is removed. Difficult, isn't it? It could be either way round and the only way to be sure is to look at the function definition.

Now look at the same call (from NSView):

Code:
[view replaceSubview:view1 with:view2;
Isn't that easier to understand? This is especially true when functions/methods take lots of BOOL arguments:

Code:
[myObject doSomethingWithX:x recursive:YES verbose:YES deleteWhenFinished:NO];
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jan 3, 2004, 07:28 PM
 
Originally posted by diamondsw:
In any other language I've seem (except Objective-C/SmallTalk), this would be setLocation(x as double, y as double) in whatever syntax the language used. The action ("setLocation") is kept distinct from the object of that action ("x" and "y").
Just as a little note, this would normally be written in Cocoa as -setLocationNSPoint)newLocation or something along those lines.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Mr Scruff
Mac Enthusiast
Join Date: Feb 2001
Location: London, UK
Status: Offline
Reply With Quote
Jan 10, 2004, 05:48 PM
 
     
St.John
Fresh-Faced Recruit
Join Date: Oct 2003
Location: Warwick, UK
Status: Offline
Reply With Quote
Jan 20, 2004, 06:53 PM
 
This thread kicks arse in a way that the mighty Kevin Ward himself would be proud of.

Thanks to everybody who has taken the time to post here; it's cleared up a lot of issues for me!

     
macgyvr64  (op)
Grizzled Veteran
Join Date: Jun 2001
Status: Offline
Reply With Quote
Jan 21, 2004, 01:57 AM
 
Me too! I'm taking an intro to Java class this semester in college, so it should realllly help (read: force) me to learn the ins and outs of Cocoa.
     
insha
Senior User
Join Date: Nov 2003
Location: Middle of the street
Status: Offline
Reply With Quote
Feb 12, 2004, 04:33 PM
 
hayesk, thank you for a clear explanation of the naming conventions in Obj-C -- I'm newbie to Cocoa and this thread has really helped me get in the right mindset for programing on the Mac platform.

     
GeeYouEye
Junior Member
Join Date: Mar 2003
Location: Walnut Creek, CA
Status: Offline
Reply With Quote
Mar 9, 2004, 02:36 AM
 
The thing about Objective-C, unlike C++ where you have to figure out one syntax quirk at a time, is that there's one moment where, suddenly, it all converges into some thing, and suddenly it all makes perfect sense. Except memory management, which I still don't get fully.
I bring order to chaos. You are in chaos windows, you are the contradiction, a bug wishing to be an OS.
     
Catfish_Man
Mac Elite
Join Date: Aug 2001
Status: Offline
Reply With Quote
Mar 9, 2004, 11:21 PM
 
Originally posted by GeeYouEye:
The thing about Objective-C, unlike C++ where you have to figure out one syntax quirk at a time, is that there's one moment where, suddenly, it all converges into some thing, and suddenly it all makes perfect sense. Except memory management, which I still don't get fully.
As far as I can tell, there isn't any sane method of memory management (aside from, maybe, garbage collection, but that's a bit slow for some things). Objective-C's is decent, but that's relative.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 07:53 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,