Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Objects and Interactions: Separate Definitions
Message-ID: <1991May22.183044.5634@Think.COM>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <3999@motcsd.csd.mot.com> <1991May21.064913.16149@netcom.COM> <1991May22.012821.12048@tkou02.enet.dec.com>
Distribution: comp
Date: Wed, 22 May 91 18:30:44 GMT

In article <1991May22.012821.12048@tkou02.enet.dec.com> diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>Responsibility for specifying a "<" operation belongs to the call site.

Which then requires the call site to know about all the possible types of
things it will compare, which is contrary to object orientation.

The problem you're running into is that there is more than one way to
compare two objects, but we'd like the generic sorter to simply use a
generic comparison operator.  Even with relatively simple data types such
as strings, there's case-sensitivity to complicate the matter.
With more complex objects, we might want to be able to sort on different
fields (e.g. use a phone database to produce a regular directory sorted by
names, and an inverse directory sorted by phone numbers).

One possible way around this would be for the generic comparison function
to take a third argument, which would be an object that represents the
style of comparison being done.  Sorry, I haven't really thought this
through, but it could contain flags such as case-sensitivity, relative
priority of fields, etc.  Making it truly generic could be tough, though;
it would probably work best in a language with good relexive capabilities
(e.g. the field priorities could be passed in as a list of slot names if
the language permits accessing slots using computed names, a la CLOS's
SLOT-VALUE function).

The other way to solve it is where I think this discussion started:
implement a class that represents the collection, and implement operations
on the collection class that do all the different sorts.  Thus, for a phone
number database, there could be SORT-JAPANESE, SORT-WESTERN, and
SORT-BY-NUMBER methods.  A single SORT method doesn't really make sense,
unless you want to unilaterally declare that one of these would be a
reasonable default and have SORT simply call it.

This parallels the real world.  If someone hands you a stack of baseball
cards and just tells you to sort it, you've got to guess what he means.  He
could want them sorted by player name, team, year, batting average, etc.
There's no such thing as a generic sort or a generic comparison operator.

-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar