Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!whuts!mtune!rutgers!ukma!uunet!tektronix!zeus!bobr
From: bobr@zeus.UUCP
Newsgroups: comp.lang.c++
Subject: Re: Re: software ICs (was Re: C++ vs Objective-C)
Message-ID: <2614@zeus.TEK.COM>
Date: Thu, 29-Oct-87 20:25:45 EST
Article-I.D.: zeus.2614
Posted: Thu Oct 29 20:25:45 1987
Date-Received: Tue, 3-Nov-87 02:24:59 EST
References: <1628@pdn.UUCP> <326@koel.rmit.oz>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 19

rcopm@koel.rmit.oz (Paul Menon) writes:

    To some, it isn't the magic we are after, it's the tedium we are not.
    Granted, the way things are (and shall be for a while) no one expects
    miracles of any environment or language.  We all have to put in the hard
    work.  But if I wanted to write a tree management package independent of
    the objects the tree stores (to cite but one example), object oriented
    programming is the answer.  If I want to use that package over and over
    again in as many places as possible, what better way is there to do it
    by making it re-usable?  This is distinct from "Libraries" like those
    found in unix.  They operate on specific types, or, more lately, operate
    on types that have been explicitly "cited" to the routine (a la
    SunView).

This flies in the face of examples like qsort() which, through the use of
specialist functions, are type independent.  Object oriented programming is
not THE answer, it is simply AN answer.
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK