Re: Grace and Maps (was Re: Development process in the Ada community)

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

"Darren New" <dnew@san.rr.com> wrote in message
news:3CC98B8E.D49A2CEE@san.rr.com...
>
> Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd
> hate to suck up and blow out a 10-meg stream file for every hit on my
> CGI site where I want to look up one record out of 100,000.
>
O.K., but that's where I'm saying we're looking at 10% of the usages. If we
presume that most of the time, we're talking about maps to hold a few
hundred employee's records, or a few dozen directories & files or whatever
an average map is likely to be used for. The structure should fit into
available memory rather easily & you may only need load/store for
persistence between program runs. If you have a few hundred thousand on up
of something, then you probably want some kind of file since you don't want
to load/store the whole thing - just access/update individual items. For
that, you have an alternative file-based map that will have a similar, but
not identical, interface.

What percentage of the time would you think that an in-memory map might be
just fine? My personal guess would be that if I had an in-memory map it
would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV)
Getting that far would satisfy some reasonably large need and the rest we
can worry about as an extra package to be added at a later date.



>
> I think that was my suggestion. Obviously, you'd need stuff like a file
> name, a utility to perhaps pack the file down to minimum size, etc. But
> my intent in saying they had the same spec was to imply that in actuall
> *access* routines, there needn't be arbitrary changes to the API. Open
> and close, sure. But not iterating thru the records, adding or deleting,
> etc.
>
O.K. Sounds like we agree. Package 1 defines the interface needed for an
in-memory map with facilities to get them in and out of streams. Package 2
defines the interface for a disk-based map that probably doesn't need
streams but would need certain file manipulation capabilities. For the
garden variety add/change/delete and scan kinds of stuff, there doesn't need
to be any difference in the interface presented. But you can't just unplug
the one and substitute the other because of some different requirements.


>
> Yah. Welcome to Java, where you need to instantiate half a dozen
> abstract mail APIs just to send an email message that's a printf in C.
> :-)
>
Sometimes, you can't avoid it, but I'd prefer to keep the names for the
things that will get used most commonly short and sweet. Don't make it
painful to use basic lists and basic maps. We can always create special
flavors that have longer names and if you need the capabilities, you put up
with the typing burden. But can you imagine the heat Ada would take if
instead of being able to declare an object as an Integer, you had to do some
version of Ada.Numerics.Scalars.Whole.Bounded.Integer? :-) Or if you simply
wanted to output an integer to the screen you had to do something like
"package My_Integer_IO is new Ada.Text_IO.Integer_IO (Num => Integer) ;"?
Wait a minute.... Ooopps! :-)

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