Collection interfaces

[Topmind]

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


No no no! I am not advocating forced time-stamps. (Although,
a sequential unique record is quite often needed. But nothing
has to be forced.)

However, timestamping *is* a common need in my domain.


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

When in doubt, leave it out.

Unless one can see and show some natural law of the Universe that
forces things into mutually-exclusive taxonomies, it is
bad, arbitrary modeling, and OO sould be ashamed of itself for
over promoting it. I hope the backlash is as strong as
the hype that propelled it onto the packaging buzzword
standards.

Some domains like chemistry, math, etc. might be able
to take advantage of natural divisions of "sub-things".
However, many domains don't, and OO seems like nothing
but added syntactical and modeling clutter without
sub-divisioning. Two out of the 3 OO Cononical Triads
depend on it. There is no polymorphism if there is
only one "type" with a bunch of independant attributes -
HAS-A reigns and sub-IS-A is rare.
(which is how it should be in biz modeling IME.)

> ....
> a general discussion of collection
> classes, IMHO, gets us closer to domains such as algebra, than
> to real-world domain modeling, anyway).

Algebra? Programming paradigms are mostly for human
communiction, not machine-to-machine. If many humans
don't model the world via algebra, then I don't see
what that gets one.


> It's unclear whether, here, you're talking about an object
> (keeping its _identity_) dynamically changing its _class_ 

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.

Look at even a call stack in an interpreter. It would
be nice to "X-ray" it and view it with different
sorts and filters for complex debugging. This is what
I like about tables. Studying the "state" of all kinds
of angles is a sinch: you don't have to re-invent 
micro querie languages, write save-to-file utilities,
etc., because they are usually built in. I like
plug-and-play power. Perhaps some bit-diddling personalities
like to re-invent little wheels, but I like to push simple
buttons and get powerful results.


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

It seems because you are USED TO refactoring when your
collection needs change. I am spoiled. I know better.

Or, your domain may be different. 

> the indisputable success
> of Smalltalk does show that ....

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.

Using procedural and table techniques, I have matched
Smalltalk "can-you-do-this" challenges in the past,
and usually with more K.I.S.S.

Thanks for your feedback
-tmind-