Collection interfaces

Topmind topmind at technologist.com
Wed Feb 28 03:11:10 CET 2001


> "Topmind" <topmind at technologist.com> wrote in message
> news:MPG.1505a76831c34b749896b3 at news.earthlink.net...
>     [snip]
> > Why can't the nodes of a multi-set ALSO have time-stamps
> > or a sequantial record/node number in them?
> 
> Because that would be unwarranted overhead on 99.947%
> of the uses of a multiset...?!
> 
> Why doesn't insertion into the multiset compute "priority"
> value according to _all_ possible formulas, as long as it's
> at it, so I can later decide that my multiset is actually a
> priority queue, too...?
> 


I am only saying that IF there are timestamps. I did NOT say
it was a prerequisite for a multi-set. You misunderstood
me.


> 
> > Requirements change and morph and merge.
> 
> And when they do, one refactors appropriately 

Refactor is a great PHB-directed euphemism for
code rework. Call it whatever you want, but it is
still unnecessary work.

The divisions of collections into types *is*
arbitrary for the most part.


> (and reruns
> one's tests -- that goes without saying).  If I need my items
> timestamped, prioritized, turned into lowercase, or maybe
> translated into Elbonian, as I insert them into a collection,
> I'll be much happier providing or choosing the appropriate
> collection, rather than have all collections try to be all things
> to all items, thank you very much.
> 

I never said that the *engine* had to provide all those
services. 

I am only selling the idea of not changing the existing
calls when collection needs are added to or change.

Born a stack != Die a stack

> 
> Alex
> 
> 
> 
> 

-tmind-



More information about the Python-list mailing list