Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.object
Subject: Re: generic sort orders
Message-ID: <1991May23.043349.24754@Think.COM>
Date: 23 May 91 04:33:49 GMT
References: <1991May22.012821.12048@tkou02.enet.dec.com> <1991May22.183044.5634@Think.COM> <1991May22.203058.15452@ccs.carleton.ca>
Sender: news@Think.COM
Reply-To: barmar@think.com
Distribution: comp
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 24

In article <1991May22.203058.15452@ccs.carleton.ca> knight@mrco.carleton.ca (Alan Knight) writes:
>In article <1991May22.183044.5634@Think.COM> barmar@think.com writes:
>>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.
>The way that this is handled in Smalltalk is fairly trivial.  There
>are three things involved, the "sortee", the "sorter", and the
>"client" (stupid terminology mine).
>    The client is whoever created the sorter, and it must supply a
>comparison function for whatever it's going to compare.

Yes, of course the "object that represents the style of comparison being
done" could be a function.  I was trying to suggest a more
"object-oriented" approach to thinking about this problem.  As I said, I
hadn't really designed the details; were I to try, I would probably give up
and just use a function.  Or perhaps a hybrid, e.g. an object that contains
some pretty generic options, along with a function that implements the more
domain-specific behavior.

-- 
Barry Margolin, Thinking Machines Corp.

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