A small tangent that might be relevant -- what's the current convention
for, say, putting several related "packages" in the same file?
In p5, I might write a great Foo.pm that loads Foo::Loader.pm and
Foo::Parser.pm and Foo::Object.pm; I'd usually drop them into seperate
files and have one load the rest, so I could just use Foo; and get on
with my code, but that does add some maintenance that could be skipped
if loading the one file automatically grabbed all the relevant parts.
Plusses and minuses there.... If the Foo:Widget and Foo:Gadget are only
of use with the something in Foo proper, maybe it would be reasonable
to toss them into the same file, though.
Looking at this proposal made me wonder if there were any value in
maybe tossing them all into one file, since that's how they'd usually
be used, but that if I just really had a use for a Foo::Parser and
didn't want any of the rest, maybe I could still
use Foo::Parser in Foo.pm;
That could load just the one section from whatever file it found in a
usual search for Foo. I really can't see that it's anything very
urgent, but maybe someone sees a use for that? It would have the
possible advantage of making the more common case be easier, and the
rarer, exceptional case be the one that takes the extra work. Even so,
I'm just not sure it's worth the work it might take to build it in.
All in all, I'm still thinking in p5, so I'd still probably do it the
old way. =o)
--- Trey Harris <[EMAIL PROTECTED]> 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.
>
> 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
>
===============================================================
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a
thumb.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
