I don't think $file1.name == $file2.name should talk to the FS,
because I think File#name t+r whatever) should return a plain Str.
Having magical FilePathName objects is handy, but sometimes you want
to get the filename as a dumb string to do stringish things without
having to worry about the fact that the string started life as the
name of a file somewhere. I could convert it explicitly, but it's
not obvious that I need to; 'name' sounds like something that should
return Str.
On 8/19/09, David Green <david.gr...@telus.net> wrote:
> 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
> IO::Metadata
> IO::Path
>
> 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.
>
>
> -David
>
>
--
Sent from my mobile device
Mark J. Reed <markjr...@gmail.com>
