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,714a8558b02b32bb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-22 05:42:29 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!newsfeeds.sol.net!logbridge.uoregon.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <400FD340.3080603@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GUI was Re: why Ada is so unpopular ? References: <100tkcshhdi686a@corp.supernews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Jan 2004 13:42:27 GMT NNTP-Posting-Host: 165.247.68.244 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1074778947 165.247.68.244 (Thu, 22 Jan 2004 05:42:27 PST) NNTP-Posting-Date: Thu, 22 Jan 2004 05:42:27 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:4644 Date: 2004-01-22T13:42:27+00:00 List-Id: Wait a minute. Aren't directories usually considered to be some kind of tree structure? Doesn't MSVC++ and the MFC supply some kind of tree widget for displaying things like directories? Seems like every time I pop up a directory on Windows, I see something that looks very reminiscent of a tree and one that looks surprisingly like the one I seem to recall was in the MFC. Maybe I'm wrong, but it looks to me like Microsoft might just be keeping some kind of tree data structure in place for handling directories. Not that the fact that Microsoft does something necessarily makes a recomendation for doing the same - but it would seem like it might not be all that painful for some apps. What would be wrong with a "Directories" package having a call that would return some kind of tree data structure? Perhaps a bunch of smaller tree-walking type subprograms might be faster - go ahead and provide that as well. But either you (the Ada vendor) are going to build a tree data structure and populate it with data or I (the app developer) am going to do it after making a bunch of more primitive calls to your library. In the first case "you" is "1 implementation effort" and in the second case "I" is "N implementation efforts" where N is the number of developers needing such a capability. Seems more efficient to do it only once. That, and it makes it darned attractive to a developer to use Ada if most of his job is already done for him. Also, assuming a "Directories" package is going to build data structures and return them, we'd likely want to have other packages operating on exactly those data structures. (A GUI library, for example) So whatever inefficiency might be there, you go through it only once and then have all your other operations making use of the result. And sometimes we just have to accept that doing some things is going to take some time. Solving an N by M matrix where N and M are big is just plain going to suck up a lot of CPU no matter who does it. Does that mean that Ada shouldn't have a matrix math package? MDC Randy Brukardt wrote: > > I can't speak for ASIS, but in the case of Directory_Operations, there is no > place where a container could usefully be used. Containers are mainly useful > in non-critical parts of your application (where time and/or space > requirements aren't critical), and that cannot be said with certainty about > the various standard libraries. Moreover, you certainly don't want searching > operations returning vectors of file names, you would have no idea > whatsoever what the time/space usage of that would be. (Directories with > thousands of files aren't uncommon.) I wrote a package which did that in the > very early days of Ada, and quickly abandoned it because of problems with > large result sets. Of course, if you need a vector of files, just create it, > it's easy enough. > > I agree with your basic point (that the libraries of Ada should be > integrated where possible), but the ones that are really bad offenders (like > the Ada.Strings hierarchy) already exist and aren't going to have major > changes in them. > > Randy. > > > > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ======================================================================