Xref: utzoo comp.object:483 comp.lang.c++:5642
Path: utzoo!attcan!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Dumb question
Message-ID: <1989Nov24.153253.9675@odi.com>
Date: 24 Nov 89 15:32:53 GMT
References: <61737@aerospace.AERO.ORG>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 36
In-Reply-To: abbott@aerospace.aero.org's message of 22 Nov 89 15:30:25 GMT

In article <61737@aerospace.AERO.ORG> abbott@aerospace.aero.org (Russell J. Abbott) writes:

   More concretely, can one write a sort routine that will sort a list of
   any type (perhaps not yet even defined) that responds to "<"?   I would
   assume that one could, but it wasn't clear to me from the C++ material
   that I have how to do it.  

What you'd have to do in C++ is:
(1) Define a base class that has a virtual less_than operation; call it xxx.
(2) Declare the sort routine to accept a (pointer to an) object of type xxx.
(3) For all the types you ever want to sort, make those types in inherit from xxx.

The compile-time type checking in C++ assures that the argument will
be an object for which less_than is declared.  This extra checking can
be helpful, catching errors at compile-time, which compensates to some
degree for the loss of flexibility compared to Smalltalk-80.

(The question of the relative values of the two approaches is extremely
complicated, depends on many other tradeoffs besides this one, and
tends to be a bit of a religious war, so won't try to elaborate on it
here.  I have now had extensive experience in both the Lisp/CLOS world
and in the C++ world, and one thing I know for sure is that each
approach has some advantages compared to the other.)

If you like the Smalltalk style that you described, but you'd like to
use C++, a good bet is to use the NIH class library (formerly known as
OOPS, available from your usual friendly distributor of public domain
software, e.g. uunet).  By using NIH classes, and deriving your own
classes from the NIH hierarchy, you can get much of the behavior
you're talking about.  This is still not as flexible as Smalltalk-80
(since you can't add new virtual function members to class Object
(without modifying the library, which can be done but has its own
drawbacks)), but it's an interesting point in tradeoff space that's
probably just right for some programmers and applications.

Dan Weinreb		Object Design, Inc.		dlw@odi.com