🚀 go-pugleaf

	Before I begin, I'd like to extend kudos to Brad Cox for so
clearly expressing the advantages of object-oriented programming and in
particular the distinction between early and late binding and the advantages/
disadvantages of both.  Now, for some comments . . .

In article <1662@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes:
>> Libraries have been around at least as
>> long as programming languages; and have contributed their share to the
>> productivity improvement, but they aren't the glorious path to
>> geometric improvement, or we would have been seeing geometric
>> improvements over the decades.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
. . .
>
>Yes, libraries HAVE been around for a long time, and they have certainly 
>not been the glorious path to geometric improvement. For example, many 
>people have worked very hard to bring about corporate-wide `reusability' 
>by collecting large libraries of functions and macros, cataloging them 
>in large databases, and publishing them for reuse. The projects have 
>generally failed, or at best brought about only arithmetic improvement. 
. . .
>They failed primarily because of a ordinary technical problem (and perhaps
>secondarily because of the usual religio-political issues that crop up 
>around code reusability). The problem is simply that code stored in a 
>conventional library is tightly coupled to the supplier's problem domain,
>and its consumers could not apply it easily in their unique environment. 
>In other words, the code is statically bound.

	I would like to add, it is also because of the lack of object-
oriented design of the libraries themselves.  When someone writes code
that depends on the specific internal representation of an object, rather
than its interface, it makes it difficult if not impossible to change those
libraries or to improve their implementation.  In addition, if the libraries
are coupled to a particular problem domain, they are in general unusable for
other, even closely similar problems.

	One of the advantages you get in a language like C++ is the ability
to specify an interface to a class which cannot be broached by casual clients.
You may access those members of a class which are public, but you cannot
access private methods (subroutines for the implementation) or directly change
data members (instance variables).  You can then change the implementation
radically, in such a way that if you were to write such a class in C
it would require changing the way you called the various method functions.
C++ provides you with the ability to maximize performance via the use of
inline methods.  You may freely change which methods are inline and which are
implemented in object code, without changing the source code of the client
at all; something which would be impossible in C.  In addition, you have the
power to redefine operators to improve code readability without adding any
additional overhead.  These features (which amount to an ability to change
the nature of the compiler in a convenient, well-specified manner) also
contribute to code reusability in that you need not modify client source
just because a library has been changed to improve performance in some way.
I recently defined a variable-length string class, defined + and += as
concatenation and append operators, and wrote some source to test it out.
I then completely reimplemented it, making + be simply an inline call to +=
with the additional creation of a temporary to hold the result.  This change
would have totally changed the source, had I written it as traditional C
function calls; however, since I simple redefined the meaning of the operators
in the header file, I didn't have to change the source one bit.

	Of course, you still have to recompile, which is a disadvantage of
C++ (over Smalltalk or Objective-C).  Nonetheless for many projects
(in particular the microcomputer project we at EA normally work on) the
efficiency of C++ is well worth the cost of recompilation.  And it's a far
sight better than having to rewrite client source.

>Building a HashTable class
>requires that all HashTable members provide hash and isEqual: methods
>that the HashTable needs.
...
>At startup time, the class will
>send itself a special message that causes HashTableMember's dispatch table
>to be inserted at the front of Object's dispatch table (taking care to 
>update the cache as well). Presto, ALL objects immediately recognize the 
>two new methods.

	Of course, one could provide a similar flexibility in C++ by providing
a parent superclass for all objects (Object).  The clients would be given
a subset of new methods which could be added to the Object class; there would
be the overhead of the users of the class having to edit their definition
files for Object, or, alternatively, relinking with a new Object library
(presuming there is only one source of modifications to Object).  One may
also choose to only make some objects subclasses of Object, for example,
a simple linked list needn't be a subclass of Object, since it is
in general not placed in a collection (such as a HashTable).  Of course,
one cannot rule out such a desire, but that's the tradeoff you get with
a language such as C++.

>If you're saying that late binding is not a panacea, I agree wholeheartedly.
>It is a tool; something to be picked up or laid aside according to the job
>at hand. I fault Smalltalk-80 for not providing any tools for doing early
>binding, and I fault Ada for not providing any tools for doing late binding.
>Both C++ and Objective-C avoid this trap, although C++ provides stronger 
>tools than C (and thus Objective-C) for doing early binding and Objective-C 
>provides stronger tools than C++ for doing late binding.

	Exactly.  My colleague Rick Tiberi drew up a sheet the other day
with a visual diagram illustrating all of the languages he has used in his
career, with the metric being both the "level" of the language as well
as how far down it let you reach.  C++ stood out among all the languages
in that it (unlike Smalltalk) allows you to implement without losing
any efficiency over a traditional language, and it also allows you to go
quite far up in terms of being able to define classes with type checking,
automatic type conversion, and protected, private, and public data and
method members (allowing object-oriented programming).  In addition, you
can choose to optimize particular classes for efficiency equal to that
of C, and to generalize other classes for flexibility approaching that of
Smalltalk.  Objective-C shares a similar range, although it provides less
support at the lower end for optimizing performance while giving more
support at the higher end for flexibility.  One can achieve similar
goals, however, in the realm of code reusability, a little more
source-code dependent in the C++ case (although it does provide
object-code reusability via virtual functions), and a little less
efficiency in the Objective-C case.

			-Mitsu Hadeishi
			 CDI Research and Development
			 Electronic Arts