On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Some ways in which different paths can be considered equivalent: Spelling: ... Simplification: ... Resolution: ... Content-wise: ...
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?

I think there's a difference between "canonical" as in a webpage with <link rel="canonical">, and "cleanup" as in Windows turning PROGRA~1 into "Program Files". There could also be other types of normalisation depending on the FS, but we probably shouldn't concern ourselves with them, other than having some way to get to such native calls.

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.

As Leon Timmermans keeps reminding us, that really should be delegated to the OS/FS. I think $file1 =:= $file2 should ask the OS whether it thinks those are the same item or not (it can check paths, it can check inodes, whatever is its official way to compare file-thingies). Similarly, $file1.name === $file2.name should ask the OS whether it thinks those names mean the same thing. And if you want to compare the canonical paths or anything else, just say $file1.name.canonical === $file2.name.canonical, or use 'eq', or whatever you want to do, just do it explicitly.

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

There are two things going on here: the user-friendly syntax for casual use, which we basically agree should be something short and pithy, although we have but begun to shed this bike, I'm sure.

    $file = io "/foo/bar";
    $file = p{/foo/bar};
    $file = Q:p/foo/bar/;
    $file = File("/foo/bar");

However we end up spelling it, we want that to give us unified access to the separate inside parts:

    IO::Data            # contents of file
    IO::Handle          # filehandle for using manually

I'm not sure why Path isn't actually just part of IO::Metadata... maybe it's just handy to have it out on its own because pathnames are so prominent. In any case, $file.size would just be shorthand for something like $file.io.metadata{size}. The :T and :B tests probably ought to be part of IO::Data, since they require opening the file to look at it; I'd rather put them there (vs. ::Metadata, which is all "outside" info) since plain ol' $file abstracts over that detail anyway. You can say $file.r, $file.x, $file.T, $file.B, and not care where those test live under the hood.

We might actually want to distinguish IO::Metadata::Stat from IO::Metadata::Xattr or something... but that's probably too FS- specific. I don't think I mind much whether it's IO::Path or IO::Metadata::Path, or whether they both as exist as synonyms....

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.

Yes.  A great mess!  Er, wait, no........

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.

Well, it's all modules anyway... certainly we'll have to rely on IO::Filesystem::XXX, but I do think this is another area to defer to the OS's own type-determining functions rather than try to do it all internally. What we should have, though, is a standard way to represent the types in Perl so that users know how to deal with them. I think roles are the obvious choice: if the OS tells you that a file is HTML, then $file would do IO::Datatype::HTML, which means in turn it would also do IO::Datatype::Plaintext, and so on.

Of course, if the OS tells you you've got a file that does IO::Datatype::Illudium-phosdex, and you want to *do* something with it, you'll need a module that knows what to do with that kind of file. Perl by itself knows only how to treat it as a string of raw bytes. Well, or as plain text. So you can treat your HTML file as plain text, or you can use HTML::Doc::Tree and treat it as something fancier.


Reply via email to