Re: Interpretation of extensions different from Unix/Linux?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1d0e8zv4oco66$.1qqitij5kmc4w$.dlg@40tude.net...
>> On Mon, 17 Aug 2009 17:28:44 -0500, Randy Brukardt wrote:
> ...
>> You manipulate it as Wide_Wide_String without conversions. The only serious
>> problem is that replacing a character in UTF8_String might change its
>> "octet" bounds and converse changing octets may change "character" bounds.
> 
> 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.

>>>> Maybe, but these are not "true" roots of the file system.
>>>
>>> What is a "true" root? There are only file names which form roots (that 
>>> is,
>>> cannot be decomposed further and still give a file or directory). It 
>>> doesn't
>>> matter where the storage is or what the technology is.
>>
>> "Untrue" roots are those Windows itself does not understand. There is a
>> large percentage of Windows programs that do not handle file names with
>> \\-stuff.
> 
> 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?

> 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.

>>>> If Ada.Directories is provided it must be specified as a useful package.
>>>> Its implementation under Windows or Unix (of which file system is no less
>>>> broken) is not a matter of concern. I see no problem with traps or even Ada
>>>> RTL starting processes and system services, if Ada.Directories has been
>>>> used by the executable. If it comes with this price I buy it. What I do not
>>>> buy is writing OS-dependent code myself.
>>>
>>> I agree, but the problem is that you are asking to write code that you ought
>>> not even be writing for Windows (and probably not for Unix as well). Ada
>>> shouldn't be in the business of encouraging you to write stupid code.
>>
>> 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.
 
>>>>> [And, yes, I agree with you that they shouldn't even have "=", but blame
>>>>> Ichbiah for making these things Strings. It's 25 years to late to change
>>>>> that definition.]
>>>>
>>>> No need to change, just overload it.
>>>
>>> Can't overload "=" for type String, as it is in Standard and the 
>>> predefined
>>> one is always visible. Any overloaded one would (almost) never be visible
>>> (use visibility has lower priority than things in Standard).
>>
>> It is not a String, it is a private type like Directory_Entry. You have to
>> overload Open, Create, Delete and Rename. That is.
> 
> 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");

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de