[% setvar title Structured Internal Representation of Filenames %]
To see what is currently happening visit http://www.perl6.org/
Structured Internal Representation of Filenames
Maintainer: Jarkko Hietaniemi <email@example.com> Date: 4 Aug 2000 Mailing List: firstname.lastname@example.org Number: 36 Version: 1 Status: Developing
Wherever Perl internally uses filenames (in a very inclusive sense: filenames, directory names, whatever) the components of the file name should be stored in a platform-neutral structured format.
Perl is great at munging data and in general Perl scripts are very portable. Howevere, before one gets to it one usually has to open some files and the results have to put somewhere. The naming of files ("files" here meant in the most inclusive possible sense, the Unix sense where everything has a name: naming of persistent storage objects, if you wll) is however one of the most unportable things there is.
A filename may have directory part, filename part, suffixes, volume names, version numbers. The component separators are different and there may be several even on a single platform. There may be one or more root directories, the notation for parent directory varies, and so on.
Perl core functions should pass filenames to and from each other as structures that contain the components of filenames in a structure. To be as future-proof as possible, the components could probably be in Unicode. For native use (when actually accessing the filesystem layer) and for performance a ready-to-be-used concatenated representation can be created on demand. Because the filename is already in parsed form, manipulation of the name is much easier and cleaner than currently. Conversion between the file naming conventions of various operating systems would become almost trivial.
A vague possibility: the proposed internal format could be designed to be flexible enough to present also URLs/URIs.
perlport manpage for discussion of filenames File::Spec File::Basename