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

[Darren New <dnew@san.rr.com>]

Marin David Condic wrote:
> 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 agree 100%. I'm just saying that one should check that other than
instantiation and destruction, one should be able to do the same things
with the new package as you did with the old. I dunno, maybe this goes
without saying in Ada, but (for example) making iterators private so you
can't easily get locked into knowing they're memory addresses instead of
file offsets, things like that. Of course, locking comes into it too,
once you get to disk-based stuff, so I think the disk stuff will be a
*superset* of the memory-based stuff. Perhaps you could even map an
instantiation of a disk-based map using the memory-based instantiator
into a temp-file-based map. But yes, this is just idle rambling at this
point.

I think another good thing would be to define the behavior of the map if
it's modified while you're iterating. Or to at a minimum make it clear
that the behavior is undefined. But if you're using a sorted map, it
shouldn't be hard to define the behavior in a relatively intuitive way.

Perhaps all I really need to be saying is that it's likely you want a
tagged type for the lists and maps, just so they *can* be extended in
the future.

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

Right. I think that's good. I'd include the streams in version 2, if
only for stuffing said maps over network connections, upgrading formats
to newer versions, etc.

Everything I snipped, I agree with.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.