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.
Your proposal would force us to have platform-dependent locations, and
hence platform-dependent programs. Do you really want to see dozens of
switches like
given $?OS {
when m:i:/win/ { use Foo in WinFoo.pm }
when m:i:/nix/ { use Foo in UnixLikeFoo.pm }
}
at the top of programs?
The broken operating system, or rather family of systems (and I converted
away from them about three years ago), still is used by 90% of users. In
practice, it does matter what happens in that environment.
Yes--but better for implementators to make that decision than for each and
every Perl programmer (most of whom will have no experience with most OS's
Perl runs on, so will be making such decisions blind!) to make them
separately (and differently).
But also consider, whatever operating system is in use, it has to know how by
default to handle a file - interpret it as a script, run it as a native
executable, pipe it to an editor or renderer etc. That information has to be
associated with the file in some way. One operating system uses name
extensions, another looks at the first line for a #! etc.
Personally, I find it useful to have a visible clue in the name (via an
extension) as to the content of the file. This seems to me more widespread
than just an OS requirement, as otherwise why have *.tar *.tar.gz *.pdf *.doc
*.png etc or even .* for hidden files in unix?
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.
By way of illustration,
% mv foo.png foo.jpg
does not convert the file's image type. If it did (or if it refused to do
the move) you'd have an argument there.
If it doesnt matter - as far as perl6 is concerned - how the module is named
(see Larry Wall's response regarding unicode and case-sensitivity), then the
extensions too are irrelevant, no? 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).
And that brings me to another question. Should it matter what the name of the
file is? For modules in perl5 as far as I can discern, the name of the module
in the file name has to conform with the package name inside the script. I
have found this default behaviour annoying at times.
To do otherwise is to again require platform-dependence. If you truly
want to force it, load the code manually with C<require> in a C<BEGIN>
block.
By extending the 'use' pragma to include information about which container it
can be found in, filenames become truly irrelevant.
Quite to the contrary--they become much more relevant.
Moreover, the initiation file for a large project might just be a
configuration file containing all the module names, together with "use
Main <main> in ProjectDebugStage.v03"
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...).
Trey
