Re: Interpretation of extensions different from Unix/Linux?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:tww2guh98m4j.vbxz4nv412g1.dlg@40tude.net...
> On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:
...
>> I think that would be prohibitively expensive in both time and space.
>
> Absolutely not. Again, Wide_Wide_String is not an implementation of
> UTF8_String, it is merely an interface. The implementation of UTF8_String
> stays an array of octets. Except for indexing which is rarely used with
> UTF8_String other operations of Wide_Wide_String can be delegated to the
> representation's operations. No overhead.

Indexing (and slicing) are pretty much the *only* operations that you do on 
a String. If they are very expensive, the entire implementation will be very 
expensive (especially as operations like "&" are already very expensive).

 ...
>> Windows surely does recognize UNC names natively - surely the file open
>> does. So by your definition these are "true" roots. There of course is a 
>> lot
>> of crappy software out there that doesn't allow them,
>
> It is not crappy, it is backward compatible. All this software uses 
> *legal*
> Windows API, and it is the API functions (16-bit or whatever) which fail 
> to
> handle fake \\nodes, useless stuff like "My Documents", "Desktop" etc. 
> This
> rubbish has nothing to do with the file system. It could be supported, no
> question, but no portable program will probably ever use it. So why should
> we care?

I have no idea what you are talking about. Every 32-bit API supports UNC 
names, and always has (at least as far back as Windows 95). I suppose there 
might be some pre-1995 programs out there that can't support such names 
because of API limitations, but what does that have to do with Ada? All of 
the Ada compilers out there for Windows are 32-bit (or more).

In any case, all of my programs are intended to be portable (to other 
compilers and to other Windows and Windows-like systems), and surely *I* 
depend a lot on UNC names (it's a heck of a lot easier to use them for file 
sharing than to create your own TCP-IP protocol!).

>> but what does that
>> have to do with Ada?? Software that supports text file names but doesn't
>> support UNC names is broken, IMHO.
>
> Nope. The design rule I propose is, any local file has to be accessible
> through at least one root determinable by Ada.Directories. The rest is up
> to the implementor's good will. This is certainly doable in any operating
> system I know.

What is a "local file"? Disk-based names are obsolete for most purposes 
(most of the devices on my latest computer don't have them), so you are 
essentially claiming that you don't want to access anything other than the 
local hard disk.

In any case, if an implementation supports UNC names (and Janus/Ada surely 
does, in *all* operations), it has to treat them as roots. And that means 
that Ada.Directories has to treat them as roots.

The fact that you and I don't even seem to agree what a root is just shows 
how silly it is to even consider trying to do this sort of stuff portably.

...
>>> Sorry, but writing a file browser is not stupid. Consider implementation
>>> of a GUI open-file dialog using Ada.Directories.
>>
>> That is *exactly* what I mean. Any "proper" Windows program will use the
>> built-in file browser, not create some less-powerful version on their 
>> own.
>
> No. First there are two (maybe three) of them under Windows. Both
> (especially the newer one) are quite unusable. The older was extensible so
> that you could add buttons and other stuff *required* by a "proper"
> applications like mine. (:-)) Under Linux the situation is much worse than
> that. So I have my own set of file selection widgets, BTW, docked widgets,
> not dialog boxes.

Barf. When you do that, you lose the capabilities that are specific to the 
particular OS, such as direct access to file shares. And they end up looking 
different than they ought to on a particular target.

In any case, both of the Windows file dialogs are extensible; I know because 
I've done it, both to test Claw and to add checkout buttons to the GUI for 
our version control front-end. It's actually pretty easy to do with Claw.

...
>> That's going to be ambiguous if you have proper string literals and very
>> hard to use if you don't.
>
> It will not:
>
>   Open (File, In_File, "C:", ("temp", "tests"), "test20", "txt");
>
> instead of
>
>   Open (File, In_File, "C:\temp\tests\test20.txt");

That's hard to use in my book. (Besides, I have no idea what you intended it 
to mean other than the Rosetta Stone-like example. It's just not readable or 
understandable.) When you get a user-provided file name (a full path like 
"\\Gatekeeper\Webroot\AdaIC\index.html", which is what you're going to get 
back from a Windows file dialog box or from a simple string entry field), 
you're going to have to parse it to get to a form like the one you are 
suggesting. And then the program will have to put it back together -- just 
adding opportunities to introduce bugs and do something other than the 
user's intent.

If you simplify it and provide an appropriate string literal converter, you 
again have the ambiguity problem (or lots of wordy junky conversions).

                                               Randy.