From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-27 17:10:56 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3CCB3E1F.8EC9DFCB@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <3CC59ED2.1000803@home.com> <3CC5B286.6FE61551@san.rr.com> <3CC5B9EE.32F3060@san.rr.com> <3CC83282.69C1884F@san.rr.com> <3CC98B8E.D49A2CEE@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Apr 2002 00:09:50 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1019952590 66.75.151.160 (Sat, 27 Apr 2002 17:09:50 PDT) NNTP-Posting-Date: Sat, 27 Apr 2002 17:09:50 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:23183 Date: 2002-04-28T00:09:50+00:00 List-Id: 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%.