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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,31af760e939556ef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Interpretation of extensions different from Unix/Linux? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net> <10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net> Date: Sat, 5 Sep 2009 10:59:52 +0200 Message-ID: <15x3ulfmh0ci2.kiac3f37illy$.dlg@40tude.net> NNTP-Posting-Date: 05 Sep 2009 10:59:50 CEST NNTP-Posting-Host: 7cbb89a1.newsspool2.arcor-online.net X-Trace: DXC=d688bLlXKdQ=>bdbdS?M0YA9EHlD;3YcR4Fo<]lROoRQ^YC2XCjHcbY2X?Mig[YN7\DNcfSJ;bb[UIRnRBaCdQKe5C6`alY X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8178 Date: 2009-09-05T10:59:50+02:00 List-Id: On Fri, 4 Sep 2009 21:08:49 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net... >> On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net... >>> ... >>>> This does not answer my question. Is file manager a typical application? >>>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI >>>> issues. >>> >>> IMHO, no, it is not a typical application. >> >> Criterion? > > Likelyhood of wanting to write it in Ada, of course. (Which ought to be > never, as I said below). 90% of any program that provides user interface dealing with files. You cannot implement file open/save/list without it. >>> You serve no one by reinventing >>> the wheel, and file managers are an integral part of every modern OS, and >>> commonly available on lots of non-modern OSes. >> >> So? Calculator program is available on all these OSes. Is it an argument >> against Ada numeric types having operation "+"? > > False analogy: "+" is useful for lots of things, not just writing a > calculator. You are talking about functionality that is *only* useful for > writing a file manager or equivalent. (And I'd argue that it isn't even > useful for that, but YMMV.) The analogy is right. The functionality of any file being reachable is essential to use a file system. Programs dealing with one or two files don't need Ada.Directories at all. Similarly, if there are only two numbers, make them named constants and forget about addition. >>> Let the user use what they >>> are familar with. If you did write one with Ada.Directories (and you >>> surely can, you just have to use some OS-specific way of finding roots), it >>> would necessarily be a poor imitation of the provided one >> >> Ada.Directories *is* a poor imitation of OS-specific file search. Why is >> it in the standard? You cannot apply this logic while keeping >> Ada.Directories. > > I totally disagree. You can write quite useful programs using > Ada.Directories without depending on anything OS-specific beyond whether or > not the package is supported at all. This is just untrue. I already have pointed out that Ada.Directories cannot be used without OS-specific programming. You cannot get file names without using string literals which *are* OS-specific. In fact not a single operation there can be used without OS-specific programming around it, unless the file name is entered from the keyboard and then used as-is, which Ada.Text_IO already does. If you put file name into a string literal, that is OS-specific. To let the user choose files from a list is OS-specific/impossible. To filter files by names is OS-specific. To compare files for identity is OS-specific. To compare file names is OS-specific. > (One obvious > example: we couldn't come up with a portable way to define a package that > could start other programs. Every compiler has this functionality, but it > isn't amenable to describing in Standards terms.) No problem with that, except the false conception, that such a package (Ada.Directories is among such) should reflect properties of the underlying OS. All Ada DB bindings suffer this same illness, which limits their usefulness but multiplies the count of. This is trivially wrong. You cannot be OS-specific and portable. Instead of that, Ada packages should provide an abstraction layer, a model OS, independent on the target. Note that all modern GUI and other middleware libraries follow this path. No problem, you can spawn a process using Glib in an OS-independent way. It would be perfectly possible to introduce Ada library for spawning processes with three pipes (represented by Ada streams). I wrote a similar thing for GtkAda based on the Glib functionality. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de