Re-thinking file test operations

This gets my vote.

A few months ago (or maybe more) I proposed making pathnames their own
type, distinct from (or perhas a subclass of) strings, but easily
constructed from strings, maybe with an operator. Having those 29
single-letter methods on such a class would not bug me as much as
having them on Str.

I agree. The built-ins of basic types like Str or Int etc need to stay pure and
just be about dealing with local data. Having methods on basic types for going
out into the wider environment like the file system is just plain wrong. There
should be separate IO classes for things like stat, which *use* basic types like
Str for their interface definitions, and the full definition of Str/etc should
not include any file-system operations.

If you go ahead and put stat ops in Str anyway, then you might as well put
things like a delete_from(Hash $arg) method on Object, which is a less
objectionable version of such backwardness.

-- Darren Duncan

Resent to list as I intended to in the first place....

On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncanwrote:
It's unclear which you are agreeing with.  By reference, it sounds
like you agree with the idea of a separate pathname type, but by
context, it sounds like you are agreeing with stat($str, :e)

Both the separate pathname type and the stat($str, :e) proposal
salvage the purity of Str, so either would be acceptable to your
argument.

I have seen other language APIs have a pathname class, usually called
FilePath or Path or similar.  Generally, I like the idea because it
allows one to abstract away from the specific form of a filename (be
it the /home/blaisepascal/.emacs/emacsrc of Unix, the C:\Documents and
Settings\Users\Blaisepascal\Local Settings\GNUEmacs\emacs.rc of
Windows, the BootDisk:Users:BlaisePascal:Settings:GNUEmacs:emacsrc of
MacOS 9, or the DKA0:[USERS.BLAISEPASCAL.SETTINGS.GNUEMACS]EMACS.RC;1
of VMS) to the basic components (devices, directories, and files).

Most of the FilePath APIs I've seen allow virtual traversal of the
path (e.g., given a FIlePath corresponding to
/home/blaisepascal/.emacs, you can ask it for the directory portion to
get /home/blaisepascal, or ask it to specify another layer, to get
/home/blaisepascal/.emacs/22.18), conversion of relative paths to
absolute paths, and perhaps even conversion of one path representation
(like Unix-style paths) to another (like HFS-style paths).

The annoying bit I've found with some APIs is that some of them force
you to use a FilePath as an argument to File.Open(), and don't always
provide an easy way to get from a string to a FilePath, forcing you to
do things like File.Open(FilePath.CurrentWorkingDirectory.AddFileName("myFile"))
to open ./myFile.

I support the idea of a separate pathname type, and I trust the Perl6
developers to make it robust but easy to use.

I don't see an ambiguity.

I am saying that the Str class should not have filesystem methods.

Routines like stat() should either be methods of a quasi-singleton FileSystem
class, or they should be subroutines in a non-OO FileSystem module.

Either way, a file name can still be represented by a Str.

Now I'm not against a distinct Filename type, in fact I'm sure its a good idea,
but I do think that users shouldn't have to use one explicitly if they don't
want to. Eg, "FileSystem.stat($str, :e)" should just DWIM.

But my main point is still that stat() etc should not be methods of Str.

-- Darren Duncan

The bigger problem of using a different type is that

"/etc/passwd" ~~ :e

Would dispatch to Str, which means that you'd need to

PathName("/etc/passwd") ~~ :e

which doesn't seem much interesting huffman-wise.

On the other hand, a multi would allow more clear semantics, and
wouldn't require an explicit typecast, as in:

stat "/etc/passwd", :e

This still allow the existance of the most specific PathName type, and a
signature like

multi stat(PathName $name, *%switches) { ... }

where...

role PathName {
multi method ACCEPTS(Str $path where { .defined }) {
$path ~~ /<PathName::token>/
}
multi method ACCEPTS(Str $path where { not .defined }) {
1;
}
}

daniel

See S32/IO document for a rough outline I did of this some time ago.
Feel free to hack away at it. Note that the documentation is spread across
- IO::FSNode
- IO::FileNode (does IO::FSNode)
- IO::DirectoryNode (does IO::FSNode)
- IO::LinkNode (does IO::FSNode)

There's also an IO::FSNodeACL class for handling permissions, but
that's only if you actually *want* to use these; the Unix ones are still there
too.

I got part way through speccing this, and then was told that my idea
for Tree-related classes couldn't be part of the core, and so I'd have to
monkey-patch them on afterwards; at that point, I went back to working on
Tree, and left the Filesystem stuff alone.

(Tree-related classes could be a role composed into both filesystem
node classes, and Match thingies returned by grammars, but alas,
monkey-patching will be necessary :) ).

:)


---------------------------------------------------------------------
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

Me too.

-Scott

That would be because it is; originally the filetests were perl5-
style, but pugs refused to parse them because you can't combine
operator and word characters in a single token. (I admit to wondering
if pugs' parse problems were enough of a reason to change them,
especially now that pugs is pretty much dead.)

Brainstorming a bit here....

Str is a class that describes collections of characters (among some other
typographical constructs, yadda, yadda, Unicode, yadda).

There is a commonly used special case, however, where my Str is not just a
Str. It is, instead, a key for an external datasource. Such cases include:

* URIs.
* Pathnames
* Usernames
* Variable names
* etc.

It makes sense to handle these cases in some regular way, and to provide
those hooks via Str because it is relatively uniquely Str's job to hold
these things (counter-examples include UIDs).

OK, so we have a need for some hookable interface on Str for accessing
external datasources by key. Let's call it "key".

$str = "/etc/aliases"
$str.e; # error, no such method
$str.key(::File);
$str.e; # works fine

There should probably be a few standard methods that are imported in this
way such as e, s, z and any other test operators that are universal, so that
this makes sense:

$user = get_user_name();
$user.key(::Getpw)
$user.e; # user exists?

$url = "http://www.example.com/";
$url.key(::URI);
$url.s > 0; # might do a HEAD request and return the size

The rest might be more domain specific:

$mailbox = "Trash";
$mailbox.key(::Mail::IMAP, $account_info);
$mailbox.msgs > 1000;

In this way you have not enforced the assumption that all strings are
pathnames, but rather that all strings might be used as keys.

I suppose this even makes sense, though it's convoluted:

$hashkey = "Aaron";
$hashkey.key(::Hash, %names);
$hashkey.e

The real beauty of this is that it can all be implemented without any
language syntax/grammar changes.

Sorry, I sent this just to Mark. Wasn't my intention.


---------- Forwarded message ----------
From: Aaron Sherman <ajs@ajs.com>
Date: Fri, Jul 10, 2009 at 6:58 PM
Subject: Re: Re-thinking file test operations
To: "Mark J. Reed" <markjreed@gmail.com>




In re-thinking it, we don't need to do either. It's already built in:

$str does Path;
if $str.e {
say("$str exists");
}

Nice and simple. All someone has to do is write the appropriate Path that
knows what to do when it's added to a Str.

I wonder if this works:

if ($str but Path).e { ... }



You've made contradictory statements, there. Either you want to change the
grammar to add new quoting styles (then the argument ensues: is YOUR key
type common enough to deserve a quoting semantic?) or you think that you
shouldn't have to customize the grammar.

I'm in favor of NOT customizing the grammar, but at the same time, I readily
admit that strings aren't always strings, and might have much more semantic
baggage that it would be good to be able to associate with them easily.

My reply to the message Aaron sent directly to me by mistake...


---------- Forwarded message ----------
From: Mark J. Reed <markjreed@gmail.com>
Date: Fri, Jul 10, 2009 at 7:23 PM
Subject: Re: Re-thinking file test operations
To: Aaron Sherman <ajs@ajs.com>


You replied just to me, you know.
Sure, but I was thinking that particular case might be common enough
to warrant something with a better Huffman encoding.

No, what I was talking about was changing the default grammar, but in
a general way, so that users who wanted their own literal syntax for
such things wouldn't have to customize the grammar themselves.  That
is, I'm arguing for a change in the design to avoid programmers having
to customize the grammar for this particular case.
Agreed.

Dunno about totally. I'm still trying to get a P6 mindset, but there's a lot to be said (evidenced by how much has been said) for having an "old-fashioned" and more familiar way to do it.

I'm underinformed, so I won't waste everyone's time on internals I haven't checked.
I'd prefer $str.File.exists; I'm not crazy about $str.f.whatever.

===============================================================
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb.