Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple should get behind Cocoa Java

On Aug 23, 2006, at 5:09 PM, Wagner Truppel wrote:


Delegation can be easily implemented using interfaces, and as far as I understand, is not a feature of the language itself, but of the Cocoa frameworks.


Delegation is distinct from interfaces & far more powerful. It is part of the runtime as you mentioned, but Cocoa==Obj-C like JavaVM==Java. Java actually took the concept of interfaces from Objective-C where they are called protocols.


With Obj-C poorly named variable names don't prevent code readability. With Java (and plain old C on which the Java syntax was based) calling the method doesn't make it clear what each argument is for, so you're constantly having to look at the docs. With Obj-C's syntax, the purpose of each argument can be very clear.

I respectfully disagree. Here's an example, using yours as a starting point:

- (void) configureObject:(MyObject *)arg1 :(NSString *)arg2 : (NSString *)arg3 :(int)arg4;

which would be called as follows: [self configureObject:arg1:arg2:arg3:arg4];

Your point would be a strong one if Obj-C *forced* the programmer to add "explanatory" pieces to each argument. As it is, it's equally as easy to write unreadable code in Obj-C as it is in Java.


Yes, it's true the programmer isn't forced to write nicely named methods, but with C/Java you don't even have the option.

The runtime features are also great, since messages to nil objects don't throw NullPointerExceptions as they do in Java, which means you don't have to put in if(obj!=null) checking code everywhere.

I happen to think that forcing me to explicitly test for a possible null pointer is a good thing. It makes me a lot more conscious about the runtime behavior of my programs. Not having to test for it opens up the possibility of unexpected and undesirable runtime behavior which may be difficult to debug. Moreover, nil objects not complaining when you send them messages doesn't translate necessarily into better code or better-behaved programs. Try releasing an object and then sending it a message.


I agree that it can be better to test for these, but my point was the language should assist the developer whenever possible. Having to constantly write !=null checks indicates to me a potential flaw.


With Objective-C if it doesn't directly handle a message, it can have a delegate object handle the message. The responder chain is probably the most powerful feature of the AppKit & it relies on message capabilities of Objective-C to do that.

Again, the responder chain and the delegation mechanism are, as far as I know, aspects of the Cocoa frameworks and not of the language itself. As such, they could equally as easily be incorporated into a Java version of Cocoa.


Absolutely correct, although like Java, the runtime(Cocoa) and language(Obj-C) are intrinsically connected. But my point was they work because of the ability to send a message to any object with Objective-C. That's not possible in Java unless you use an interface, which means more code & then your implementation of the interface isn't a true implementation, but a message forwarder, so the language contract of an interface isn't fulfilled. Effectively Java isn't Java anymore, but a hack to make it behave like Obj-C.

A few things I'd like to add in favor of Java which you haven't touched on:

a) in Java you don't have an interface file separate from its implementation, which I happen to like
b) in Java you can have static variables and static methods with their own visibility modifiers; in Obj-C, as far as I know, there are no static variables in the sense of class variables (you have to fake them)
c) it's a lot easier (with much less typing) to define private methods in Java than in Obj-C
d) Java automatically supports forward class declarations; in Obj-C you need to use the @class directive
e) the whole pointer notation is so outdated... granted, it's not a terribly complicated concept to grasp (first-year CS students might disagree), but why impose on programmers another layer of thinking when the language can take care of it for them? How many times have you accidentally typed foo.x rather than foo->x?

To summarize, I won't deny that Obj-C is more dynamic than Java (mainly because of the 'id' data type), but I think it would be equally as easy, from a technical perspective alone, to implement Cocoa in Java as it was in Obj-C. Then, again, I'm not an Apple engineer faced with that prospect, so it's easy for me to make that claim...

a) There is no requirement for the interface & implementation to be separate files. It's merely a convention carried over from C. In fact, there isn't a requirement for each class to be in it's own file, like Java, but simply convention to make it easier to handle.
b)@private @protected & @public are instance variable modifiers in Obj-C also. True, no static variables... you'd use a global variable in that case from C which wouldn't have a visibility marker as you pointed out.
c)True no absolutely restricted private method, just instance variables. You can use a hidden type of private method in Obj-C by not declaring the method in the interface, but only in the implementation, but that is security thru obscurity in practice.
d)Not sure what you mean here. @class is basically an alternative to #import, which basically says a class with this name exists, while #import describes the class fully.
e)That foo->x syntax applies to retrieving instance variables or use in structs, it's not pointer notation. Although the *object and &object pointer notation of C is definitely annoying and is an implementation detail the language should obfuscate like Java does.

One other aspect of Java (&C++) that I'd like to see in Obj-C is namespace (a.k.a packages). Putting everything in the default package in Java would be a pain & that's what you have to do with Obj- C. Don't get me wrong, I love Java and continue to use it for most projects, but I think there are nice things about Obj-C too. However, I think it's best to leverage advantages of any language for the situation. The cocoa frameworks are inherently tied to Obj-C's language abilities. While you can approximate it with another language, like Cocoa-Java tried, it's inherently a kludge. Engineering time could better be spent adding functionality to cocoa rather than duplicating the functionality in another language. Cocoa- Java had a run of several years & never was really utilized by the development community. Apple obviously looked at that & considered whether they would have their engineers work on continuing to support Cocoa-Java and the Java-bridge thus duplicating existing Obj-C functionality, or divert those engineers to improving cocoa or improving plain old java. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Re: Apple should get behind Cocoa Java (From: Wagner Truppel <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.