Re: Interpretation of extensions different from Unix/Linux?

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

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:tww2guh98m4j.vbxz4nv412g1.dlg@xxxxxxxxxxxxx
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
.

Relevant Pages

  • Re: Interpretation of extensions different from Unix/Linux?
    ... "Untrue" roots are those Windows itself does not understand. ... No need to change, just overload it. ... It is not a String, it is a private type like Directory_Entry. ...
    (comp.lang.ada)
  • Re: Interpretation of extensions different from Unix/Linux?
    ... "Untrue" roots are those Windows itself does not understand. ... No need to change, just overload it. ... It is not a String, it is a private type like Directory_Entry. ...
    (comp.lang.ada)
  • Re: How to store a lot of files on a harddrive?
    ... I've though about converting the number into a string, ... I have been programming with small xml files for some time now so here ... I am not sure if you can do this on windows!! ... ZFS - Zettabyte File System designed by Sun Microsystems and under the ...
    (comp.programming)
  • Re: Ada.Directories problems, a summary
    ... Name encoding. ... Either String versions should be UTF-8 or else replaced ... string names to file system names? ... example, to find drive letters under Windows, network shares, mount points ...
    (comp.lang.ada)
  • Re: why use the sealed ?
    ... system that supports inheritance and polymorphism is to promote reusability. ... Find great Windows Forms articles in Windows Forms Tips and Tricks ... >> exceeds past the end of the string. ... >> application to be a Remoting Client. ...
    (microsoft.public.dotnet.languages.csharp)