Internal Filename Representations (was Re: Summary of I/O related RFCs)

[cc'ed on internals as FYI]

> =item 36 (v1): Structured Internal Representation of Filenames

I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too cumbersome.
Plus, on Windows it turns into junk like "file://C|/Windows". Icky.

Here's an idea. Our new nifty fileobjects ($fo) could have some "jars"
where path info is stuck internally automatically. We could have methods
for:

   $fo->pathdrive   # Windows drive
   $fo->patharray   # array of split-up filename
   $fo->pathdelim   # / or \ or :: or ?????

So trace this call:

   $fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR";

   $fo->pathdrive = "C:" ;
   $fo->patharray = [ Windows, System, IOSUBSYS, RMM.PDR ];
   $fo->pathdelim = "\";

So, this would be the internal representation of the filename. A UNIX
one would be similar, it's just that the drive jar would be empty:

   $fo = open "/etc/inet/inetd.conf";

   $fo->pathdrive = ""; 
   $fo->patharray = [ etc, inet, inetd.conf ];
   $fo->pathdelim = "/";

Splitting apart or putting together either one of these paths is trivial
- it requires
the exact same operations as long as you know the delimiter (the OS
should tell you that):

   ($fo->pathdrive, $fo->patharray) = split $fo->pathdelim, $filename;
   $filename = join $fo->pathdelim, $fo->pathdrive, $fo->patharray;

Hey, I kinda like that...(of course, I'm biased)... :-)

-Nate


P.S. I know the split code won't work exactly like that (assigning to
funcs as lvalues), but I thought it was the clearest way to write it.