# 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 ---------------------------------------------------