On 1/7/08, Trey Harris wrote:
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:

May I suggest the following extension to the 'use ' pragma, viz.
use <module name written in unicode and case sensitive> in <filename as constrained by local system>

Oh please, no.
The entire point of the wording currently in the synopsis is so that we can have platform-independent location of libraries. The "name mangling capability" hypothesized lets the same C<use> get the requested resource, regardless of the file (or database location!) where the resource is actually located on the platform running Perl.

Yes, and having a proper library-manager to take care of all those details will be a big improvement (e.g. Perl/Parrot can cache pre-compiled versions because the library will know when things change and need updating). But that comes at a cost: you can't simply use some file you have lying about, you have to "load" it into the library somehow first. So I'll run something like "plib load --lang=perl some/file/path.pm", which takes care of specifying the <filename as constrained by local system>. (Parrot will figure out the module name by looking in the module itself.)

Still, we also want a way to use arbitrary files without the overhead of going through the official library; something similar to the way Perl 5 searches the current dir (if a requested module isn't in the "library", which for P5 is just a list of dirs in @INC -- well, "." is just the last element of @INC by default, so I guess it's part of the "library" too). So we do need a way to say "look in the current dir" or "look in this place" for bare files. And presumably you can still say "use lib 'path'" in P6; but then we will need a way to specify how to translate the module name into a filename.

That still doesn't mean that you need to be able to specify the translation -- it could be predetermined, based on the OS/filesystem you're using (e.g. if you're running Windows, the rule might be files have to end in ".pm"; if you're using HFS+ on a Mac, it will look for a case-insensitive filename; for ISO-9660, Unicode chars might have to be %-encoded, etc.). (That assumes we can always tell what FS we're using.)

However, that also means that the filename (however encoded) has to match the module name. That's often fine, but sometimes inconvenient. (E.g. the default translation policy might specify that the local filepath would have to be 7 subdirs deep.) It'd be much nicer to be able to say something like: use Some::Fancy::Module::Name::Supercalifragilisticexpialidocious in "./Supe.new".

I'm not worried about platform-independence because this is something that typically applies when you're developing a module; once you're ready to deploy or distribute it, you'd probably make a package that officially "librarified" anything that needed to be. Portability, independence, etc. are very important, but I don't think they should be mandatory unless you can get them for free, and library-management cannot be completely transparent, so there should be ways around it.

The .tar, etc., are typically named for transport, where you may need to know the filetype without having the benefit of its contents for examination. *.pdf and *.doc are filetypes that did not exist until after Windows did, and so the required-extension behavior ossified. The .* convention merely came about because it was a convenient kludge put into ls for the purpose.

To be fair, they're all "convenient kludges" -- the problem isn't Windows per se, the problem is filesystems that don't have a real place for type metadata, which includes Unix as much as DOS, er, Windows. Knowing the type of a file is valuable for lots of reasons; it's just that in pre-GUI days, the primitive command-line interface obscured some of the primitiveness of the FS.

So if I choose to call my perl6 scripts *.p6 it should not matter? Other than for the sake of tradition or conformity with the tribe's sense of propriety :)
Sure, knock yourself out. Call it ".perl6" if you like, or ".niftynewlanguagethatisn'tquitecompatiblewith.pl" (except those violate eight.3 rules).

If one extension is bad, then surely a dozen are worse? So although technically it's not necessary (personally, I hate filename extensions), lots of people will be using them anyway -- we may as well come up with a suggested community preference rather than everyone coming up with something different.

And that configuration file would be a huge comb of $?OS and $?OSVER switches in a typical platform-independent development. And even so, the whole thing would be far more brittle than the automatic-location system we have today, as problematic as it is (not very, actually...).

Yup. Although I can't resist pointing out the that system we have today uses extensions. Well, you could argue that the required ".pm" is a "suffix" rather than an "extension" (in the Windows sense). I think a primary raison d'etre is so you can have a module "Foo" which is really Foo.pm and a directory "Foo" for sub-modules. But not being allowed to have a file and a dir of the same name is itself merely an unnecessary restriction that just happens to be implemented by some currently-popular filesystems.


Reply via email to