Re: Interpretation of extensions different from Unix/Linux?

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

On Mon, 17 Aug 2009 17:28:44 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:cbxuxz06dr5r$.9zo0supfl50x.dlg@40tude.net...
>> On Fri, 14 Aug 2009 18:54:40 -0500, Randy Brukardt wrote:
> ...
>>> You mean, "Ada cannot provide this optimally". As far as the ARG is
>>> concerned, a UTF-8 encoded string is a String. We looked at other options
>>> and decided they weren't worth the effort.
>>
>> But UTF-8 encoded string is a Wide_Wide_String. The elements of a Unicode
>> string are code points (Wide_Wide_Character). It is only the 
>> representation
>> which is a string of octets (not Character!). Who should care of
>> representations in Ada?
> 
> If course you care of representations. A Wide_Wide_String takes 4 times as 
> much space as a UTF-8 encoded string, which can be a severe performance 
> drag. And if you *don't* care about representation, then just store 
> everything as Wide_Wide_String and do not worry about the representation at 
> all.

Wide_Wide_String is an interface of UTF-8 string. It is *not* its
representation. Consider it in not-Ada:

   type Wide_Wide_String is interface
      array (Positive range <>) of Wide_Wide_Character;

   type Octet_No is range 1..<implementation_defined>;
   type Octet is mod 2**8:
   type UTF8_String is new Wide_Wide_String with
      array (Octet_No range <>) of Octet;

> For Ada purposes, UTF-8 is a storage format, not an operation format. You 
> manipulate a Wide_Wide_Character string, then convert to/from UTF-8 for 
> storage only.

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.

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

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

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

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