import conundrum






According to the documentation for "use", if one wants to prevent
a module's import from being called when the module is use'd, one
is supposed pass an empty list as the second argument to "use":

use Foo::Bar ();

But now suppose that Foo::Bar in turn use's some other module Foo:

############################################################
# Foo/Bar.pm
package Foo::Bar;
use Foo;

# yadda-yadda

1;
__END__
############################################################

and, furthermore, suppose that Foo *has* an import method:

############################################################
# Foo.pm
package Foo;

sub import {
shift->go_nuts( @_ );
}

# yadda-yadda

1;
__END__
############################################################

In this case, even if the user loads Foo/Bar.pm with "use Foo::Bar
()", Foo::import is still invoked.

My problem is this: how to give the users of Foo::Bar the opportunity
to veto the calling of Foo::import? The only approach I can think
of is to define a Foo::Bar::import method whose only function is
to call Foo::import, and change the line "use Foo" to "use Foo ()":

############################################################
# Bar/Foo.pm
package Foo::Bar;

use Foo ();

sub import {
shift;
Foo->import( @_ );
}

# yadda-yadda

1;
__END__
############################################################

This does indeed have the effect of "transmitting" the "()" argument
from "use Foo::Bar ()" through to Foo. But in a suite of modules
of any complexity this approach quickly becomes cumbersome.

Is there any other for Foo to know that it has been use'd by a
module that *itself* was use'd with a "()" argument?

TIA!

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
.



Relevant Pages

  • Re: from __future__ import absolute_import ?
    ... foo not in bar ... A path below the package level is generally a good means to shoot ... to represent a python "package" structure. ...
    (comp.lang.python)
  • Re: A Question about DEFPACKAGE syntax
    ... Lisp and for not-really-Common-Lisp ... that it's easier to type:foo than to type "FOO". ... "FOO" does not create superficial symbols in the keyword package ...
    (comp.lang.lisp)
  • Re: Request for help constructing a simple macro
    ... Isn't an unbound symbol just a `symbol object'? ... Object in Lisp means generally all Lisp data. ... #:FOO ... No package for this symbol. ...
    (comp.lang.lisp)
  • Re: from __future__ import absolute_import ?
    ... foo not in bar ... Unfortunately this is a side effect of using the os's directory structure to represent a python "package" structure. ...
    (comp.lang.python)
  • Re: Best Practices - common code
    ... >> Let's say that we have a bunch of independent projects, among them Foo ... all of this common code ... > you can break up the bulk along package or package family* lines. ... > Ant can analyze class dependencies. ...
    (comp.lang.java.programmer)