Re: Container reqs

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ug08jtoa9.fsf@gsfc.nasa.gov...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> > For example: Why not produce a set of packages that supports a) a
> > homogeneous bi-directional list and b) a homogeneous map? I'll concede
to
> > the need for a static & dynamic version of each. That would be what gets
> > called in the technical papers "A Good Start"(tm).
>
> I agree. My set of components does not currently provide a "homogenous
> map". At least, I don't think it does - I'm not sure you define that
> the same way I do.
>
By a "homogenous map" I mean something that roughly approximates an indexed
file. (See the MFC for what they call a "Map") Basically, there is a need
for some kind of in-memory data structure that might hold, for example,
employee names as a string associated to employee records such that
retrieval out of the map is based on the employee name.

Homogeneous in the sense that the bulk of standard issue applications for a
Map need not hold some kind of heterogenous data based on some "root
object". No need to have pointers to some 'class - although that might be
"Nice To Have"(tm). (I'd avoid making it a requirement - but if you support
it, cool!)


> So, how about you download my components, add a homogeneous map, and
> then somebody else can add what they want.
>
> I know, someone will chime in with "Why start with Stephe's instead of
> the Booch Components?". Well, that is exactly the question we need to
> be discussing now.
>
I'm willing to start from anywhere provided there is some modicum of
concensus that "anywhere" is the right thing to adopt. (I didn't much like
the Ada.Strings... packages because they weren't what I would have built,
but I dropped my own string tools when the basic services were available in
a standard package. Better to be in-sync and consistent even if it isn't
what I might view as the ultimate answer.)

As for consensus, I reiterate that the key players will be one or more of
the compiler vendors. If you're willing to have your components distributed
by the vendors and they're willing to accept/distribute some version of
them, I'd get behind it and be willing to help out. If you really want to
get your stuff adopted as the "standard" you might consider trying to enlist
a vendor or two. This is one of those "Time To Market" thingies wherein the
first guy to get adopted and out there wins the debate. What everyone else
thinks won't matter so long as your code is at minimum "sufficient".


> Several people have put together what they consider "A Good Start".
> The question is, is there enough consensus for any one of these to
> convince the rest of us to jump on board, and integrate our stuff into
> it (instead of the other way around).
>

I don't think you'll ever get a consensus debating it here. Get a vendor to
back it and it will likely win. I think it was Charles Colson of the Nixon
Whitehouse who once said "When you've got them by the balls, their hearts
and minds will follow..." Whatever gets distributed widely and integrated
into a number of projects will end up becoming too hard to resist.


>
> Perhaps you could vote on the several that are out there, indicating
> which one most closely fits _your_ needs. Then everyone else could do
> the same. Some data would be useful here.
>
My preferences aren't that strong provided there is some minimal, simple way
to get a handful of the most commonly used structures. (That, and having it
under a license that isn't infectious.) Mostly, I want to use whatever is
going to have some acceptance by the vendors.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/