Re: Interpretation of extensions different from Unix/Linux?

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

"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. (If 
you don't care about time and space, then there is no reason to use UTF-8 or 
UTF-16 in the first place.)

>>> 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, but what does that 
have to do with Ada?? Software that supports text file names but doesn't 
support UNC names is broken, IMHO.

>>> 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. 
(Indeed, this was one of the primary reasons we created Claw.) Any decent 
GUI will have a way to do that (and if it is portable, will have to provide 
similar functionality on other systems). That's way outside of Ada's sphere.

>>>> [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. We created a package like that for use within the 
Janus/Ada toolset, and using it is very complicated -- it takes many lines 
of code to do anything - no matter how simple. I don't think anyone would 
use such a contraption.

                                       Randy.