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