2000-08-09-21:00:31 Chaim Frenkel:
> Making a module local to the using package, might have interesting
> properties. [...]
> The only breakage that I see, is having some way of globally setting
> a variable. For example, turning on debugging for all uses. (FTP::Debug
> I find quite popular.)
>
> Can anyone see any other breakage?
Not other breakage, but another example of the same exact class
of breakage. In RFC 70 I proposed some (hopefully minor) language
cleanups to make it possible to have Fatal.pm actually work the
way people want it. If it worked, then Fatal.pm would be getting
some categories it supported, e.g. "use Fatal qw(:io);". I then
suggested that the invoked categories could be posted into a
testable variable, in case other module authors wished to cooperate
with this protocol.
If the only real problem that can be found with making module use
package-local is in these few option-flag type variables, perhaps
they could be handled differently. E.g. suppose normal package
variables end up being local to the package that "use"-es the
package, and when a package actually wants to make a genuine global
for all users of the package, it explicitly tucks it into a variable
whose name starts with main::. E.g. let Net/FTP.pm post its debug
flag into $main::Net::FTP::Debug, and the list of exception classes
requested of Fatal.pm could be posted into @main::Fatal.
The next natural thought seems to be that the module creating such
a global should check and see if it's being used by main, and
only post into the global if so, otherwise let its option[s] be
user-local. Can import() use caller() this way? That would allow
a module author to e.g. code their module using Fatal, without
affecting anything outside their module, while allowing main's
invocation (if any) of Fatal to offer guidance to other modules that
chose to try and honor it.
-Bennett
PGP signature
