Re: Interpretation of extensions different from Unix/Linux?

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

On Wed, 19 Aug 2009 17:40:06 -0500, Randy Brukardt wrote:

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

Expensive than what? There is no any cheaper way to index characters of an
UTF-8 string. It not expensive it how it is. Do you propose not to provide
indexing characters of a UTF-8 string?

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

No, I think that this includes NT4, 95, 98, ME. But I am lazy to verify it.

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

Yes, if we are talking about file systems. There can be various extensions
of the file system notion. But the minimal required support is obviously
the local drives and virtual drives. Beyond that I would leave it to the
vendor. If he decides to support data sources (ODBC), code source
versioning systems (Subversion), or field-bus devices, be it so. 

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

I have nothing against it, except that Ada standard cannot mandate the way
roots are to be enumerated under Windows. What it has to mandate is that an
ability to enumerate roots shall be provided.

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

No, it shows that Windows is a silly OS. But that should not prevent us
from having sound standard libraries.

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

Yes, this is the Value function, which takes an OS-specific String or
Wide_Wide_String and returns Directory_Entry object (or whatever). This
object can be used in Open either directly:

   Open (File, In_File, Value (Get_Text (Widget)));;

 or as above:

   declare
      Name : Directory_Entry := Value (Get_Text (Widget));
   begin
      Open (File, In_File, Device (Name), Path (Name), Base_Name (Name),
Extension (Name));

---------
Look when you read a number from a text entry box, does that imply that
Integer must be String? Is it Ada or Perl?

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

No bug is possible as it is typed.

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

It is far more, it is sane way to have literals of file names. These
literal are OS-independent:

"Gatekeeper", ("Webroot", "AdaIC"), "index", "html"

We could also add operations to compose such literals in other ways:

"Gatekeeper" mod "Webroot" / "AdaIC" * "index" & "html"

The choice of operation names is left to your imagination.

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