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.
I never said that delegation and interfaces are the same thing. I
said that delegation can be implemented using interfaces.
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.
I see your point now, and I agree.
That's not possible in Java unless you use an interface, which
means more code
True.
& 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.
Again, I beg to differ. I'm sure you're aware of the Chain Of
Responsibility design pattern, which is really what Cocoa's Responder
Chain implements.
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.
True. I had forgotten about that.
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.
I meant that you can't #import "ClassA.h" in ClassB's interface file
while at the same time #importing "ClassB.h" in ClassA's interface
file. You need to use the @class directive and that's an unnecessary
hassle, in my opinion.
e)That foo->x syntax applies to retrieving instance variables or
use in structs, it's not pointer notation.
Huh? You're confusing me now... in
NSObject *obj;
isn't obj a *pointer* to an object? Can you not de-reference it to
access its instance variable x by writing obj->x? In what way is that
*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.
Indeed. In fact, this and other examples we both have mentioned (and
possibly others which we have not), I suspect, are the reasons why
Elliotte Harold said "This thread convinced me to start reading about
Objective-C. More soon, but the short version is GACK! This is not a
modern language." (Elliotte, if I'm putting words in your mouth, I
apologize.)
One other aspect of Java (&C++) that I'd like to see in Obj-C is
namespace (a.k.a packages).
Absolutely! I had forgotten to mention that, and it's a big one.
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.
Hence my suggestion of starting a parallel project to implement Cocoa
in a new language that incorporates the best features of both
languages while dropping all the unnecessary baggage carried over
from C. But, like I said before, I'm not an Apple engineer nor a
seasoned Cocoa programmer, nor am I ruler of the universe (not yet,
that is), so what I said is nothing more than the opinion of an
outsider.
As such, I think I'll stop contributing to this thread, since it's
veered way off-course and, in any case, I have nothing else of value
to add to it.
Wagner
============
Hey, what's new?
E over h...
_______________________________________________
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
