On Sun, Aug 12, 2012 at 1:08 PM, Linda Walsh <perlbug-followup@perl.org> wrote: > [snip] > border between classes and packages, and the fear of 'use <pkgname>' > trying to use 'auto-semantics' to determine if it should look for > pkgname in the LIB list. My view is that there is *no* border between classes and packages, because the former has no (current) meaning in Perl 5. A "class" is just a namespace, i.e. a package, that happens to have a reference blessed to it. There is an often blurry border between "package" (namespace) and "module" (a .pm file). E.g. both "use" and "require" can load a module, which may or may not contain a package of the corresponding name. I.e. a module contains zero or more package declarations; these may or may not correspond to the bareword "name" of the module before it is translated into a path to search @INC. So, with that in mind, I could see benefit in trying to clarify what people intend, and to allow people to "use" a bareword without needing to worry whether it's in a module or already loaded as part of another module. However, I don't think "class" is an appropriate keyword for it, as that already has lots of overloaded meanings (and desired meanings) and I don't see this specific feature consistent with or clarifying any of those. I do think it would be appropriate to prototype such a capability on CPAN and see if there is widespread adoption. For example, this would be trivially easy and less verbose than direct %INC hacking: package Foo::Bar; use Inc::Loaded; # import sets caller as loaded in %INC A more sophisticated approach could use the hoookable parser to do this: use Devel::InnerClass; innerclass Foo::Bar { ... } (The phrase "innerclass" seems less likely to conflict with what people expect of a "class" keyword.) I tend to think either of those would be better places to start than by adding a new keyword to the core. -- DavidThread Previous | Thread Next