Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mcnc!uvaarpa!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: CHALLENGE: heterogeneous collections
Message-ID: <26MAR91.19392004@uc780.umd.edu>
Date: 26 Mar 91 19:39:20 GMT
References: <pallas.669923769@red-dwarf> <48805@nigel.ee.udel.edu> <25MAR91.22422777@uc780.umd.edu> <48913@nigel.ee.udel.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 74
Nntp-Posting-Host: uc780.umd.edu

Darren New      >> >  or >
Me              >>
>> >Hmm...  How about a window with a hetrogeneous collection of buttons,
>> >sliders, text displays, etc, all of which respond to "redraw" and "is
>> >the mouse over you"?
>>The way I look at things, I'd probably think of that as a homogenous
>>collection.
>Hmm... a homogenous collection that when you take it apart yields things
>with different types. Somehow, I think we are confused over terminology.
>Either that, or you are reaching for straws :-) The whole point of
>a hetrogeneous collection is that sometimes you treat everything
>the same and sometimes you treat each thing differently.

Well.. my view is "type is a form of information", and you seem to be
agreeing with me.  For instance, consider a list of numbers: 
(0, 1, 2, 3, 4).  Now consider a function, "f" which rounds a number
up to the nearest even integer.  Applying f to that list would yield
(0, 2, 2, 4, 4).  Voila!  Hetrogenous data.  (-: I believe you said
"The whole point of a hetrogenous collection is that sometimes you
treat everything the same and sometimes you treat each thing
differently.")

More generally, if your language allows you to encapsulate data, so
that the encapsulated information is invisible to the user, then
the type of that information should be invisible (until you "take it
out of its box").  Anything less is not true encapsulation.  At least,
that's the way I look at things...

>Let's call a "hetrogeneous collection" something that holds
>multiple values of multiple types and over which some code iterates
>(hence the "collection" part) and over which other code applies
>different functions depending on the type (hence the "hetrogeneous"
>part). 

Heh.. but type is just information, in my opinion.

By the way, the way I'd write code to deal with the original challenge
would be something like this:
  c =. a, b
  foo c
  display c

or should that be
  c =. a, b
  display c
  foo c

(I don't remember the particulars)

Without some more detail on what the pieces were, I hesitate to write
"foo" and "display".  As a first cut though, I could make foo be an
identity function, and display simply dump the data to standard
output.

>If this isn't a good enough definition, then all I can say is
>"When you drive screws with a hammer, *nothing* looks like a
>screwdriver."

But I'm using neither a screwdriver nor a hammer.  I'm using a
computer ;-)

>In the above case, the routine to refresh the screen will iterate over
>the entire collection, while the routine to actually do the redrawing
>(which clearly must be dynamically bound) will do different things
>based on the type (slider, button, ...) of the object. Looks like a
>hetrogeneous collection to me.

It's ok.  If I was writing the routine to actually do the redrawing,
I'd probably think it was a hetrogenous collection too.  And if you've
seen some of my other postings, you might get the idea that I consider
dynamic binding (of both functions and data) as pretty fundamental in
general.

Raul Rockwell