Collection interfaces

[John Schmitt]

> -----Original Message-----
> From: topmind at technologist.com [mailto:topmind at technologist.com]
> Sent: Wednesday, February 28, 2001 7:56 AM
> To: python-list at python.org
> Subject: Re: Collection interfaces

[lots of deletia]

> No! There is no class to change to. There would be *one*
> and only one collection protocol. Not all engines would
> implement every feature of the protocol, but the idea
> is that you don't pick a protocol that STICKS you with
> only say stack-centric protocols or commands.
> 
> I don't know about your domain, but I observe collections
> changing and growing in my domain. Starting out with
> just a dictionary (hash) can be a real pain if you later
> need more columns or more indexes, for example.

I choose collections based on their behaviours.  So, I would chose a stack
collection because retreiving the most recently pushed object is very quick
(O(1)) while other operations are more expensive and not needed for my
domain.  If I needed random access, I would chose some other collection
based on its random access costs.

Just how do you choose a collection class?  It sounds like you look for the
collection that does everything with considering its performance or costs.  

[even more deletia]

> I would hardly call it "indisputed". Smalltalk is sort of
> the Frank Zappa of programming languages. It gets rave
> reviews and it is intellectually stimulating. However,
> it never quite catches on with general programmers.
> 
> I think because its power does not live up to it's haughtiness.

I have not written even a single line of Smalltalk code, so I have no
experience with it.  But I hope to look at it someday for the same reason I
looked at Python - someone said it was interesting.  Are you saying that
Smalltalk (or other languages (SML would be my favourite)) failed
commercially due to a lack of technical merits rather than marketing effort?
I would be inclined to believe that Smalltalk's commercial failure would be
due in part to decisons made by PHBs.

[still more deletia]

John