Collection interfaces (Was: New to OO concepts - re-usability)

[Topmind]

> 
> "Topmind" <topmind at technologist.com> wrote
> in message news:MPG.1503548620e632919896a4 at news.earthlink.net...
> > > >
> > > > This is a sore point with me. To me it seems silly (artificial)
> > > > to split collection handling into categories (stacks, sets, trees,
> etc.).
> > > > If needs change from one to another or a combo, then you are hosed
> > > > with a non-fitting interface.
> > >
> > > Yes, and so OO language provide an advantage here. Collection classes
> > > in these languages are accessible through common interfaces. You don't
> > > care how they are implemented, you only care about the interface.
> >
> > You mean something like SQL or ODBC?
> 
> No, I mean collections, as with, say, the Smalltalk collection classes.
> 

Smalltalk uses collection taxonomies, which I frown on.
Collection needs change, morph, and grow. If you tie your
application to a specific "type", then the chances of
getting screwed are high IME.

If Smalltalk wants to rewrite them so features can be
mixed and match as needed, instead of based on an limiting
taxonomy, that would be great. (I am working on 
my version of such a spec, BTW.)

OO thinking is taxonomy-happy. I see it in collections,
streams, and GUI's. One can have many more variations if
you treat features as indepedent. Sure, not all combinations
are valid, but the pattern of invalidity is not a
tree pattern for the most part.


> > And, this crap that only OO can do implimentation-hiding interfaces is
> > pure propaganda.
> 
> It is possible to hide the implementation behind any procedure. But
> it requires some kind of OO mechanism to be polymorphic. That
> is what OO is, by definition.
> 

Whatever. It is not much difference to the user of such API's, mostly a 
matter of verb position.

x.movenext
movenext(x)

tamato 
tamato


> --
> Patrick Logan
> mailto:patrickdlogan at home.com
> 
> 

-tmind-