While many people think of Java as being close to C++, this is not really true. The syntax is vaguely like C++, but semantically it inherits a lot from Objective-C. This is not surprising, since a lot of the people who worked on Java came from NeXT or were involved with OpenStep at Sun.
Java was designed as a language for “average programmers,” incorporating an object model similar to Objective-C and syntax from C++. If you have used Java, Objective-C will be familiar to you. The type system is similar, with object types identified by interfaces and a few primitive or intrinsic types. Objective-C class methods became Java static methods. Objective-C protocols became Java interfaces. Objective-C categories are not present in Java. The differences between Objective-C and C++ are much more profound. Objective-C was created by adding Smalltalk-like extensions to C. C++ was created by adding Simula-like extensions to C. Although Simula is often called the first object-oriented language, it fails Ingalls’ test.
C++ classes are not real objects. You cannot use them as you would objects, and the dispatch mechanism is very different. At first glance, it appears that message dispatch in Objective-C is similar to calling a virtual method in C++. This is not the case, however. C++ supports multiple inheritance, and to do this implements some very complex casting rules. When you cast a pointer to an object in Objective-C to a pointer to another object, no code is generated by the compiler. In C++, the result of a pointer cast can be a different address. When you call a doSomething() virtual method in C++, you are doing this kind of pointer cast on the vtable.
A vtable is the closest thing C++ gets to a class object, although it’s not exposed at the language level. A vtable is simply an array of function pointers. Each virtual method in a class has an offset in the vtable and an entry. When you create a subclass in C++, you get a new vtable for each superclass. When you then cast the object to one of these superclasses (implicitly or explicitly), you get a structure containing a pointer to this vtable. Calling methods then calls the function at the specified offset.
This means that you can have two objects implementing virtual methods with the same name, but if they don’t have a common superclass that declares that method as virtual, you can’t call them both the same way. In Objective-C, method lookups depend on just the class of the receiver and the message name. You can use two objects interchangeably if they implement the same methods, even if they do not share a common superclass. This eliminates a lot of the need for multiple inheritance.
While the semantic differences are the most important, the syntactic differences are the most obvious. C++ and Java borrow syntax from C structures for method calls. Objective-C, in contrast, uses Smalltalk syntax enclosed in square brackets. The following is an example of inserting an object into a Java Dictionary object and a Cocoa NSMutableDictonary:
// Java
aDict.put(a, b);
// Objective-C
[aDict setObject: b forKey: a];
The Java code is shorter, but a lot less readable. Without checking the documentation, or being familiar with the API in question, you wouldn’t know that a is the key and b is the value. In contrast, you can’t read the Objective-C code without being aware of this (as long as you can read English).
This is one of the things that makes Cocoa nicer to use than many competing frameworks. Because the language forces you to name every parameter, code using large APIs is much easier to read without having to become intimately familiar with every single class and method. It also makes it very easy to learn the API; you will never find yourself having to consult the documentation for the order of parameters if you can remember the method names. There’s no reason that Java couldn’t have used putKeyValue() or similar as the method name, but it didn’t. Cocoa always does.
Source of Information : Addison Wesley - Cocoa Programming Developers Handbook (December 2009)
Java was designed as a language for “average programmers,” incorporating an object model similar to Objective-C and syntax from C++. If you have used Java, Objective-C will be familiar to you. The type system is similar, with object types identified by interfaces and a few primitive or intrinsic types. Objective-C class methods became Java static methods. Objective-C protocols became Java interfaces. Objective-C categories are not present in Java. The differences between Objective-C and C++ are much more profound. Objective-C was created by adding Smalltalk-like extensions to C. C++ was created by adding Simula-like extensions to C. Although Simula is often called the first object-oriented language, it fails Ingalls’ test.
C++ classes are not real objects. You cannot use them as you would objects, and the dispatch mechanism is very different. At first glance, it appears that message dispatch in Objective-C is similar to calling a virtual method in C++. This is not the case, however. C++ supports multiple inheritance, and to do this implements some very complex casting rules. When you cast a pointer to an object in Objective-C to a pointer to another object, no code is generated by the compiler. In C++, the result of a pointer cast can be a different address. When you call a doSomething() virtual method in C++, you are doing this kind of pointer cast on the vtable.
A vtable is the closest thing C++ gets to a class object, although it’s not exposed at the language level. A vtable is simply an array of function pointers. Each virtual method in a class has an offset in the vtable and an entry. When you create a subclass in C++, you get a new vtable for each superclass. When you then cast the object to one of these superclasses (implicitly or explicitly), you get a structure containing a pointer to this vtable. Calling methods then calls the function at the specified offset.
This means that you can have two objects implementing virtual methods with the same name, but if they don’t have a common superclass that declares that method as virtual, you can’t call them both the same way. In Objective-C, method lookups depend on just the class of the receiver and the message name. You can use two objects interchangeably if they implement the same methods, even if they do not share a common superclass. This eliminates a lot of the need for multiple inheritance.
While the semantic differences are the most important, the syntactic differences are the most obvious. C++ and Java borrow syntax from C structures for method calls. Objective-C, in contrast, uses Smalltalk syntax enclosed in square brackets. The following is an example of inserting an object into a Java Dictionary object and a Cocoa NSMutableDictonary:
// Java
aDict.put(a, b);
// Objective-C
[aDict setObject: b forKey: a];
The Java code is shorter, but a lot less readable. Without checking the documentation, or being familiar with the API in question, you wouldn’t know that a is the key and b is the value. In contrast, you can’t read the Objective-C code without being aware of this (as long as you can read English).
This is one of the things that makes Cocoa nicer to use than many competing frameworks. Because the language forces you to name every parameter, code using large APIs is much easier to read without having to become intimately familiar with every single class and method. It also makes it very easy to learn the API; you will never find yourself having to consult the documentation for the order of parameters if you can remember the method names. There’s no reason that Java couldn’t have used putKeyValue() or similar as the method name, but it didn’t. Cocoa always does.
Source of Information : Addison Wesley - Cocoa Programming Developers Handbook (December 2009)
|
|
0 comments
Post a Comment