🚀 go-pugleaf

In article <509@drexel.UUCP>, rickers@drexel.UUCP (Rick Wargo) writes:
> In article <1811@watcgl.waterloo.edu>, kdmoen@watcgl.waterloo.edu (Doug Moen) writes:
> > csrdi@its63b.ed.ac.uk (Rick Innis, CS4) writes:
> > >... I'd also like C++, and may well end up porting
> > >that myself, but I've been told that Objective-C is a better language -
> > 
> > Strange... My understanding is that C++ is the better language.
> 
> As usual - which is the "better" language?  All things are created to serve
> some purpose and both of the aforementioned languages fulfill certain needs.
> 

In general, I agree with Doug's comparison of Objective-C and C++, except
for the following:

> The dynamic binding is what seperates Objective-C from C++.  It is just
> a wonderful and powerful feature.  It gives an object the freedom of
> not having to recognize all types of messages at compile time, instead
> it can be done at run-time (yes, at a cost of speed - but Objective-C 
> uses a quick routine to send messages to objects, using a internal hash
> table).  And okay, before I get flamed, C++ does have those virtual
> functions, but they are not as easy to use as Objective-C's messages
> (my own opinion!).  Try building and utilizing a hetergeneous list
> in both languages.  I found the Objective-C code to be more logical and
> easier to read and smaller in source code size) than a similar routine
> written in C++.

The reason that it might appear difficult at first to do polymorphic
data structures in C++ is that C++ as it comes out of the box doesn't
include any of the necessary scaffolding that Objective-C comes with,
nor are there any complete examples to use as a guide.  I spent months
figuring out how to write fundamental Smalltalk-80/Objective-C -like
classes in C++ and, like standing an egg on its end, once you see how
it's done, it's easy (and elegant, I might add).  I won't get into
details here -- my code, the OOPS class library, is in the public
domain.

The big difference between the way C++ and Objective-C support O-OP is
that C++ is statically typed while Objective-C, like Smalltalk-80, is
dynamically typed.  But if C++ is statically typed, how can it have
dynamic binding?  Let me explain the difference with an example.

Suppose we have a base class called Object and two derived classes
(subclasses) String and Rectangle.  We want to be able to print Objects,
Strings, and Rectangles, and we want to be able to calculate the area
of a Rectangle.  Note that print is a general function, one that makes
sense for any class (at least for debugging purposes), while area only
makes sense for Rectangles.

In Objective-C, we could define print() as a method for classes String
and Rectangle, and we could define area() as a method for only class
Rectangle.  Even if print() and area() were not defined for class Object,
we could write a program that attempted to print an Object and
calculate its area, and we would not get any complaint from the
preprocessor.  If at run time the Object was in fact a String, we
would be able to print it, but area() would fail with a "method not
found" error.

In C++, we could define print() as a member function for classes
String and Rectangle, and we could define area() as a member function
for only class Rectangle.  However, we would also need to declare (not
implement) print() as a virtual member function of class Object;
otherwise, the C++ preprocessor would complain if we wrote a program
that attempted to print an Object.  Once this is done, C++ behaves the
same as Objective-C when we try to print an Object -- both Strings and
Rectangles print as we have defined that operation for their specific
class.  Note that since area() is not declared as a member function of
class Object, we would get a diagnostic from the C++ preprocessor
rather than a run-time error if our program attempted to invoke area()
on an Object.  In C++, if we had an Object that might be a Rectangle
at run time that we wished to find the area of, we would first need to
verify the class of the object by calling a function like
isKindOf(Rectangle), and if it was, we would type cast it to class
Rectangle and call area().  In many circumstances, the explicit
run-time type check can be eliminated because we can arrange to have
C++'s compile-time type checking guarantee that a type cast is safe.

In my opinion, C++ -style static typing is better because (1) it is
more efficient.  In effect, Objective-C always does a run-time type
check in its method lookup, whereas in C++ we can often eliminate it,
and (2) C++ programs are easier to comprehend because variable types
are usually explicit in the code.  In Objective-C all objects are
declared as type id, and the type of the object that the programmer
expects to be working with (i.e., the methods he expects the object to
implement) must be deduced from the code or documentation.




-- 
	Keith Gorlen			phone: (301) 496-5363
	Building 12A, Room 2017		uucp: uunet!mimsy!elsie!nih-csl!keith
	National Institutes of Health
	Bethesda, MD 20892