I agree with most of what you said (see below where I don't), but my
point was (and I still maintain it) that Apple's decision to stick
with Obj-C was more a matter of saving money than the advantages of
the language. Of course, I can't prove my suspicions and, therefore,
there's not much point in arguing about them, so I won't try. I just
thought I'd mention a reason that no one, as far as I can tell, had
mentioned before in this list.
Another powerful feature is delegates.
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.
Although it was written long ago, Objective-C is a well thought out
language and offers unique capabilities like Categories that allow
alternatives to subclassing.
I have to admit that I really don't truly understand the advantages
of Categories. But, then, I'm new to Obj-C and Cocoa, so in time I
shall grasp it.
For me, that's been the one difficulty with C-based languages,
although Obj-C's retain/release system is fundamentally how Java
works, the only difference being that the runtime handles that
automatically in Java instead of the developer in Obj-C... at least
for now.
My understanding is that the retain/release convention is not a
feature of the language itself, but a "rule" that is followed
throughout the Cocoa frameworks.
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:
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.
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.
Also you can send any message (method) to any object. If it has the
method, it runs it, otherwise it ignores it like other dynamic
languages. Java added functionality to allow for more dynamic calls
with reflection, but that's still a pain to use.
I agree that Java's reflection mechanism is a bit painful to use,
since you have to test for several possible exceptions, but it's not
too difficult to get around that.
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.
So while Java has been adding features that get close to Obj-C in
the past few releases, Objective-C has had them for almost twenty
years.
It's the second time you say that, but the only feature that's been
added to Java which is close in some sense to Obj-C has been
reflection. And since Obj-C is now gaining automatic garbage
collection, I'd say the game is even.
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...
Wagner
============
"Greetings, Professor Falken. A strange game.
The only winning move is not to play.
How about a nice game of chess?"
- Joshua, in "Wargames"
_______________________________________________
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
