# from Matisse Enzer
# on Friday 14 March 2008 12:20:
>and when you see a
>"use" statement, you know what the corresponding package is, and have
> a good clue about the path path of the file you are importing.
Well, a "use" statement literally defines the name of the file (per
`perldoc -f require`), but also the package of the import() method.
While one *can* have a package name which doesn't match the file path,
the 'use' statement still has to point at the file -- but that sort of
inner switcharoo is extremely non-discoverable and is likely to lead to
puzzling:
# loads package Deal, but calls Foo::Bar->import()
use Foo::Bar;
# much, much later ...
my $thing = Deal->new;
By "discoverable", I mean that when a constructor is called on a class,
I expect to be able to hit '*' in vim and soon find a corresponding
'use' or 'require' statement. This also ties to the rule of least
surprise.
Now, the "Foo/Bar.pm contains Foo::Bar and Foo::Bar::Whatever" issue is
slightly different. I would call that situation acceptable, but
typically as an interim measure -- and generally only to the extent
that Foo::Bar::Whatever does not, in itself, have much importance or
require easily accessible documentation (that is: when it has
"importance", you probably want `perldoc Foo::Bar::Whatever` to work.)
Aside: I have often wished that base.pm had simply said eval("require
$base") and been done with it (instead of all this mincing %{"$base::"}
stuff (not to mention the timidity about $SIG{__DIE__} again.)) That
would at least have made the error message much less ambiguous.
--Eric
--
But as soon as you hear the Doppler shift dropping in pitch, you know
that they're probably going to miss your house, because if they were on
a collision course with your house, the pitch would stay the same until
impact. As I said, that one's subtle.
--Larry Wall
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
