Path: utzoo!censor!geac!jtsv16!uunet!samsung!ctrsol!emory!nastar!joel
From: joel@nastar.UUCP (Joel Rives)
Newsgroups: comp.object
Subject: Re: Understanding the Object-Oriented Life-Cycle
Message-ID: <654@nastar.UUCP>
Date: 10 Nov 89 15:13:36 GMT
References: <5026@internal.Apple.COM> <315@shrike.AUSTIN.LOCKHEED.COM>
Reply-To: joel@nastar.UUCP (Joel Rives)
Organization: Digital Transmissions Systems, Inc.
Lines: 20

>aihaug@AUSTIN.LOCKHEED.COM (Daniel A Haug) (aihaug@AUSTIN.LOCKHEED.COM, <315@shrike.AUSTIN.LOCKHEED.COM>):
>By far (IMHO), the largest advantage to this is in code extensibility,
>or reusability.  It is so incredibly useful to define an algorithm
>that doesn't care about the types on which it operates.  For example,
>I need only implement a priority queue ADT once.  The algorithm is the
>same, but the types can be whatever.  As result, I only need to write
>one QUEUE and DEQUE procedure that don't depend on any typing.  Then,
>every object that is passed into the queue would need to support 
>some sort of comparison method that QUEUE would call to determine
>proper placement.

Perhaps, i am misunderstanding the point you are making here. It is not at
all difficult to code a QUEUE object in C++ that will accept a generic 
reference upon which to operate. A new instantiation of this QUEUE object
could be passed a comparison function when created that would be specific
to the data type being queued. Actually, i can think of a couple of different
ways to approach this problem --largely asthetic in their differences. As in
the above example, the algorithm need be coded only once.

Joel