Re: List Containers - The Road Ahead

[Ted Dennison<dennison@telepath.com>]

In article <9semrm$i79$1@nh.pace.co.uk>, Marin David Condic says...
>
>Maps should look as much like lists as possible. Similar names &
>functionality. It might be better to defer Maps until some kind of decision
>is taken about lists.

>"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
>news:9sdpku$eu2$1@news.huji.ac.il...
>>
>> That's for lists.
>> To see how the universal the design can be, can someone propose a
>> Map/Dictionary Strawman?

I'd say that we should at least finish getting the kinks out of the iterators
before trying to synthesize a "Maps" package, since it will need them too.

I started with Lists for 3 reasons:

1)  I've implemented a lot of simple ones myself over the years (there are at
least 2 in OpenToken), so I have a bit of experience and could do it quickly.

2)  I think lists and maps should look consistent, so much of the work in
figuring out how the Maps package works would be done in the process of getting
Lists nailed down.

3)  I didn't think that our discussion of Maps had really progressed to that
point yet. I still don't think we are quite there yet, but it may be time to
start talking more seriously. 

For one small example:

What is the general opinion about using private "key" types in the Maps generic?
Remember that this will mean that "<" is not available. Perhaps that's OK if we
provide a boolean comparison routine as another generic parameter, although that
raises the complexity a bit. But then, should we attempt to make that parmemter
consistent with what is done for the "Sort" routine? How exactly?

We also have yet to have the discussion where someone wants "keys" to be their
own generic package/type that then gets passed into "Sort" generics and into
Maps, and hasn't considered how this complicates use. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.