use is just require + import at compile time.

 BEGIN { require Module; Module->import( LIST ); }

• The require will happen only once (it sets and checks %INC, there is no point in loading the code multiple times from disk)
• the ->import() method will (must) be called each (compile) time.

One is free to use import for any kind of compile time effects (like executing a source filter or activating pragmas or even calling extend() )

This is correct, and in this case the base class uses -somefeature to activate a pragma, scoped using %^H. People have been wondering how multiple users of the same base class within the same application would be able to keep track of whether -somefeature is in effect. They probably haven't read (or don't recall reading) perlpragma. ...or possibly wish they never had read it. This is obviously not trivial magic.

So this is a case where a base class is designed to be inherited from, and to optionally provide some additional behavior, tracked as a pragma. The extends mechanism on its own doesn't accommodate this particular need. It's looking like the simplest approach is a use followed by an extends. That's fine, but consider this:

[non-Moose base class implementing -somefeature pragma]
    <- [Moose-style base class adapter passing through -somefeature pr
+agma]
        <- [broad range of subclasses that inherit from Moose-style ba
+se class, and that may or may not want to invoke -somefeature]
[download]

We've been able to manage the pass-through just fine, but extends alone isn't sufficient for making it work without use.

package NonMooseBase;

sub import {
    # I'll spare you the treachery.
}

...

1;




package MooseBase;

use Moose;
use NonMooseBase;
extends 'NonMooseBase';

...

1;



package MySubclass;

extends 'MooseBase';
use MooseBase -somepragma;

...

1;
[download]

This probably will work. As long as inheritance is in place, the presence of the import list in use MooseBase -somepragma will cause ->import() to be called, and it gets inherited from NonMooseBase. We're already handling inheritance depth correctly and twiddling %^H appropriately. The one fly in the ointment was providing a Moosey intermediate class to allow new work to benefit from Moose without losing the useful tools built into the old-school base class.




Dave

I have trouble to understand the concept of a lexically scoped base class, and that's what %^H is normally used for.

But I think instead of hacking Moose, you should try to hide all magic inside an MagicBase::import() which calls extends in the callers package for you and just do use MagicBase qw/-feature/ .

Like that you avoid boilerplating hacks and you can put all magical documentation inside your module.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Wikisyntax for the Monastery}