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-20 12:49:35 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newshub.sdsu.edu!cox.net!news2.east.cox.net.POSTED!53ab2750!not-for-mail Message-ID: <3CC1C6B3.6060306@telepath.com> From: Ted Dennison User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 20 Apr 2002 19:49:33 GMT NNTP-Posting-Host: 68.12.51.201 X-Complaints-To: abuse@cox.net X-Trace: news2.east.cox.net 1019332173 68.12.51.201 (Sat, 20 Apr 2002 15:49:33 EDT) NNTP-Posting-Date: Sat, 20 Apr 2002 15:49:33 EDT Organization: Cox Communications Xref: archiver1.google.com comp.lang.ada:22831 Date: 2002-04-20T19:49:33+00:00 List-Id: Marin David Condic wrote: > "Ted Dennison" wrote in message > news:4519e058.0204190529.559a47ae@posting.google.com... > >>I've actually been thinking along similar lines. What I'm wondering is >>if we should keep the list package as "Lists.Unbounded", or if we >>should just bag the whole bounded/unbounded issue and make it "Lists". >> >> >> > O.K. Let's cash in our reality checks and see if they bounce. Would it be > fair to say that *most* Ada developers and applications are some flavor of > Windows/Unix with no realtime requirement beyond "Don't run so slow as to > annoy the user..."? If that's the case, then we're looking at virtual memory I honestly have no clue. The vast majority of my Ada use has been real-time or embedded (where dynamic allocation is often unavailable), and I do notice that there seem to be a large number of Ada compilers for such platforms. But I also realise that's just the view from my window, not a scientific representative sample. What I was thinking is that we have 2 reasonable approaches: The first would be to keep "Lists" as a parent package with an "Unbounded" child. The main advantage to this, and the reason it currently is this way, is that it matches what we already have in place for string support. Another possiblity would be to keep the name simple (Grace.Lists), and give the bounded version its own name when/if the time comes. Something like "Circular_Lists" (or Booch's "Ring") might be a possibility. This concept extends to Maps too, as we could call them "Maps" and "Hashes" rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a simpler structure, we no longer have the name talking about internal features of the structure instead of external features. That could be good enough for real-time and embedded folks if we document its use (or lack of use) of heap properly. But the argument for consistency with Ada.Strings.* is fairly compelling too. > An interesting observation: When I write most apps for a PC in Ada, I tend > to use the standard, fixed strings only at the points where Ada defined > functions require them. (Stuff like Text_IO) The rest of the time, I just go > to Unbounded because from a programming perspective, its just so much more > convenient. In most instances, whatever performance penalties might exist That's funny. If anything, I'm the opposite. I go with fixed strings wherever I can without having to keep a separate length variable (which can be nearly anywhere once you learn how to do it). Text_IO.Get_Line is the annyoing exception where I'd like to use Unbounded, but can't. Strings a generally the kind of object that only holds one value for their entire lifetime. The trick is that figuring out what the proper one value is can sometimes be a bit of work. Reading textual input is the primary significant exception to this. > My inclination would be to make Grace.Lists and Grace.Maps and add children > at a later date if we thought we needed special cases. I'd again make an > appeal for some version of "Grace.Containers.Lists" and > "Grace.Containers.Maps" (or some variant thereof) so that there might also > be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML", > "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real > important to me but thinking along the line of problem domains & dividing > things up under a subheading is something I think would be beneficial in the > long run. I'm curious if other people feel this way. I'd lean towards "Grace.Lists", as the standard Ada library is equally flat, our list of components may not end up being large, and there isn't liable to be much common code sitting in the "Components" spec. But I'm not married to the idea. We certianly need to name for proper growth, as renaming files in CVS is kind of a kludge. > I've still got the link bookmarked and could possibly spend some time > developing some test code, etc., if you think that's of value. (Do you have > a body in some preliminary state I could work to?) Its actually pretty much done. It could perhaps use some more testing. But we just need to arrive at a proper name, and I'll check it into Grace's CVS. > I don't think you need to have the full-blown project setup done in order to > discuss an interface to Maps. What would you suggest as a means of getting > that ball rolling? Would you like someone to take the Lists spec and turn it > into a strawman for Maps? (I hear you're a little preoccupied at the > moment... :-) Yeah, that would be a good start. Right now in addtion to this I'm trying to figure out if I need to buy 3 smaller child car seats or a larger car. :-(