Collection interfaces

[Alex Martelli]

"Topmind" <topmind at technologist.com> wrote in message
news:MPG.1506007591cf818b9896bc at news.earthlink.net...
> > "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.

IF there are to be timestamps on insertion of items into a
collection, a rare but far from unthinkable requirement, I do
not want the collection to do it behind my back -- just as I
do not want "prioritizing" to be happening without me knowing
that (and thus being able, if need be, to customize the way
items are timestamped, prioritized, etc).


> > > 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.

There is definitely a lot of arbitrariness if the division
is made into a _taxonomy_ -- as single-inheritance thinking
may suggest.  I'm definitely not advocating or defending
the exclusive use of taxonomy, which IMHO tends to breed a
somewhat warped worldview -- the natural view of abstract
algebra does not lead to that, for example; in chains of
specialization such as groupoid->semigroup->monoid->group,
one may add a condition such as 'commutative' at different
steps, so there is no taxonomic 'single-inheritance' chain
leading to 'Abelian group'.  However, reacting to the
modeling over-restrictiveness of taxonomy with a bid to
drop all _classification_ is, IMHO, an over-reaction; there
IS a lot of structure in classification-_DAG_s, after all
(and I'm not entering, here, into the issue of whether
taxonomy is 'close enough' to effectively model *real-world*
domains for programming purposes -- the indisputable success
of Smalltalk does show that single-inheritance is *practically
workable* for many tasks -- a general discussion of collection
classes, IMHO, gets us closer to domains such as algebra, than
to real-world domain modeling, anyway).


> 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

It's unclear whether, here, you're talking about an object
(keeping its _identity_) dynamically changing its _class_ (I
didn't think Smalltalk supported that, but I may easily be
wrong on that score; Python certainly does).  In my humble
opinion, though, such extreme dynamism, while sometimes it
proves VERY pragmatically useful (e.g., change a "proxy"
placeholder class to a full-blown implementation class in
a demand-driven, just-in-time manner), is not normally very
useful in the _modeling_ (analysis) phase -- reasoning in
terms of 'unchanging' class-membership tends to simplify
the analysis, even if practical needs drive one to make use
of the extremely-dynamic approaches in design & coding.

Assuming you're not talking of runtime class-changes, but
of modeling-time (analysis-time) 'behavior', then I'd still
want to refactor when the needs have changed so much as to
make me need (e.g.) a multiset where I used to use a stack.
But then, I addressed the refactoring issue (and what it
implies in terms of process and mindset) in another post to
this thread a very short time ago -- and I haven't read
anything from you that would change my mind on that (surely
not the lava-flow-prone approach in the URL you gave:-).


Alex