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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-26 20:46:14 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.nuthinbutnews.com!propagator-sterling!news-in.nuthinbutnews.com!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) Date: Fri, 26 Apr 2002 13:53:11 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: 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> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1019843592 3633 136.170.200.133 (26 Apr 2002 17:53:12 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 26 Apr 2002 17:53:12 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:23160 Date: 2002-04-26T17:53:12+00:00 List-Id: "Darren New" 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