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/nmeersschaert%
40mac.com
This email sent to email@hidden
