On Tue, 18 Aug 2009, David Green wrote:

On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
      Well, my main thought in this context is that the stuff that can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are differences, but the two are a lot
the same), whereas metadata makes less sense in the context of TCP sockets;

But any IO object might have metadata; some different from the metadata you traditionally get with files, and some the same, e.g. $io.size, $io.times{modified}, $io.charset, $io.type.

        Ok, now you're giving me ideas :).

[snipped a bit and moved it further down the e-mail]
      I guess what I'm saying here is that I think we can do the things
without people having to worry about the objects being separate unless they
care.  So, separate objects, but hide it as much as possible.  Is that
something you're fine with?

Yes -- to me that means some class/role that wraps up all the pieces together, but all the separate components are still there underneath. But I'm not too bothered about how it's implemented as long as it's transparent for casual use.

  my $file = io p[/some/file];
  my $contents = $file.data;
  my $mod-date = $file.times{modified};
  my $size = $file.size;

        That sounds like the kind of thing I'm heading for.

Pathnames still are strings, so that's fine. In fact, there are different
      As for pathnames being strings, you may be right FSVO string.  But
I'd say that, while they may be strings, they're not Str, but they do Str

Agreed, pathnames are "almost" strings, but worth distinguishing conceptually. There should be a URL type that does Str.

Actually, there are other differences, like case-insensitivity and illegal chars. Unfortunately, those depend on the given filesystem. As long as you're dealing with one FS at a time, that's OK; it probably means we have IO::Name::ext3, IO::Name::NTFS, IO::Name::HFS, etc. But what happens when you cross FS-barriers? Does a case-sensitive name match a case-insensitive one? Is filename-equality not commutative or not transitive? If you're looking for a filename "foo" on Mac/Win, then a file actually called "FOO" matches; but on Unix it wouldn't.

(Actually, Macs can do both IO::Name::HFS::case-insensitive and IO::Name::HFS::case-sensitive. Eek.)

        I think it should depend on the set of constraints involved.

I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings.

Well, the *files* are the same, but the pathnames are different. I'm not sure whether some differences in "spelling" should be ignored by default or not. There are actually several different kinds; S32 has a method "realpath", but I think "canonical" is a better name, because aliases can be just as "real" as the canonical path, e.g. a web page with multiple addresses. Or hard links rather than soft links -- though in that case, there is no one "canonical" path. It may not even be possible to easily tell if there is one or not.

Some ways in which different paths can be considered equivalent:
  Spelling: C:\PROGRA~1, case-insensitivity
  Simplification: foo/../bar/ to bar/
  Resolution: of symlinks/shortcuts
  Content-wise: hard links/multiple addresses

Depending on the circumstances, you might want any of those to count as the "same" file; or none of them. We'll need methods for each sort of transformation, $path.canonical, $path.normalize, $path.simplify, etc. Two high-level IO objects are "the same", regardless of path, if $file2 =:= $file2 (which might compare inodes, etc.). There should be a way to set what level of sameness applies in a given lexical scope; perhaps the first two listed above are a reasonable default to start with.

Ok, my next commit will have "canonpath" (stolen directly from p5's File::Spec documentation), which will do "No physical check on the filesystem, but a logical cleanup of a path", and "realpath" (idea taken from p5's Cwd documentation), which will resolve symlinks, etc, and provide an absolute path. Oh, and "resolvepath", which does both. I'm not quite sure I followed all your discussion above -- have I left something out?

Anyway, my assumption is that there should be a number of comparison options. Since we do Str, we should get string comparison for free. But I'm expecting other options at other levels, but have no idea how or what at this point.

There's something that slightly jars me here... I don't like the quotation returning an IO object.
But doesn't normal quoting return a Str object? And regex quoting return an object (Regex? Match? Something, anyway).

Certainly, but a regex doesn't produce a Signature object, say. I don't object to objects, just to creating objects, then doing something with them, then returning another kind of object, and calling that "parsing". If we're parsing the characters, we should end up with an IO::Name. If we end up with an IO::actual-file/stream-whatever, then we should call it something else (like an "io constructor").

According to my last commit, p{} will return a Path object that just stores the path, but has methods attached for accessing all the metadata. But it doesn't do file opening or things like that (unless you use the :T and :B thingies, which read the first block and try to guess whether it's text or binary -- these are in Perl 5 too).

[This bit was further up the e-mail, but I moved it here]
if (path{/path/to/file}.e) {
      @lines = slurp(path{/path/to/file});
      (I'm using one of David's suggested syntaxes above, but I'm not
closely attached to it).

I suggested variations along the line of: io "/path/to/file". It amounts to much the same thing, but it's important conceptually to distinguish a pathname from the thing it names. (A path doesn't have a modification date, a file does.) Also, special quoting/escaping could apply to other things, not limited to "filenames". That said, I don't think it's unreasonable to want to combine both operations for brevity, but the io-constructor should have built-in path parsing, not the other way around.

        Did my answer above answer the concerns here?

The difference in our approaches is that you seem keen to integrate
closely the data and the metadata, whereas I'm trying to integrate the paths
and the metadata.

Well, paths are just metadata too, although typically the most important kind. (You could even have an IO without a path or name.) I want a view that integrates all of them, because that's how people ordinarily think about files, unless they have a specific reason not to.

I think we want many of the same things, I'm just expressing them slightly differently. Let's keep working on this, and hopefully we end up with something great.

I was wanting to replace the "glob" language with something more like XPath, but that idea was vetoed by people who didn't want Tree-related objects to be part of the core, so I'm doing that as a library.

I'm all for some tree-related fun(ctions). A tree is basically a hash of hashes, so I'm surprised we don't have a few functions for traversing them and other very basic hashy concepts. But I would like to see XPath-type stuff hashed out [pun intended] anyway -- whether it ends up in a third-party module or not isn't such a big deal when it comes to P6, and somebody will have to figure how to do it in a perlish way eventually.

That would be me. I have some code, but I'm waiting on improvements in Rakudo (and btw, thanks to the Rakudo guys for doing a wonderful job).

if $file.type ~~ MIME("text/plain") {...}
Cool idea.  How would the type be determined?  Are you thinking of
the algorithms in the unix "file" utility?  Please tell me you're not
planning to use filename extentions -- that's bad :).
Wouldn't $file.type be metadata?

Yes; and yes, filename extensions are evil, but of course thanks to primitive filesystems, we're stuck with them to a large extent. And there's no perfect solution, but it would be useful for Perl to stick as closely as the FS/OS's idea of types as it can. Sometimes that would mean looking up an extension; it might mean using (or emulating) "file" magic; it might mean querying the FS for a MIME-type or a UTI. After all, the filename extension may not actually match the correct type of the file.

My suggestion would be that it's an interesting idea, but should maybe be left to a module, since it's not a small problem. Of course, I'm happy to be overruled by a higher power :). I'd like the feature, I'm just unsure it deserved core status.

        Anyway, HTH,

| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayl...@wayland.id.au    | I am                           |

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-

Reply via email to