Re: Re (tilly) 1: Passing parameters to a module's import function

[rrwo]

I've already been experimenting with something like the import function you've shown. But by "no such facility exists in Exporter" I mean that you can't have the following in your module:

  package MyModule;

  use Exporter;

  @ISA = qw( Exporter );

  @EXPORT_OK = qw( mysub anothersub );

  @ATTRIBUTES = qw( foo bar );

so that in your module you could use:

  use MyModule qw( anothersub ), { foo => 1 };

It would be a good feature for Exporter. (Ideally one would specify required attributes and maybe specify types, default values, etc.).

UPDATE: Ok, I've corrected the formatting. Didn't realize CODE was converted to PRE.

[tilly]

First of all please use <code> tags rather than doing your own formatting. (Cleaner, people can download your code, etc.)

Anyways this feature makes me deeply suspicious. What is this for? Personally I like using modules that are designed to be used multiple times in multiple places. This looks like it would be used to initialize a number of globals in the module. That would mean that if I used modules A and B which both used C, I could get hosed. But I shouldn't need to know anything about what A and B do internally. Therefore C should be designed so that can be used by multiple modules at the same time without any conflict.

Hmmmm..

I could be very wrong, but my inclination would be to ask how your module is structured, and ask whether there is a cleaner design that could be used. For instance use an OO style where you pass parameters into new()...

Incidentally your comment about specifying types raises another design flag for me. Perl is untyped, and does not have a type system in the sense that you see in other languages. Trying to mix concepts from a type system with Perl is generally a sign that you are doing something wrong (or using the wrong tool).

I don't mean to sound so down on your feature request. Why don't you describe in more detail what a sample problem is where you would find this useful, and we can see whether there is another way to organize this?

[rrwo]

Your point about multiple modules using it is a good one. However, this module is not likely to be used by anything other than a main program (it's a version of Win32::EventLog::Carp which traps warnings and fatals and posts them in the Windows NT event log; I'd like to give the option of specifying a different source name, so that related scripts can show up in the logs using one name than each individual script's file name.)

I'm experimenting with various ways to handling this. By specifying these options upon importing, compilation errors and warnings will be logged under the parameters specified--as "FooProject" rather than "index.pl" and logged in the System log rather than Application log, for instance.

This is a very specialized case, so it probably would make more sense in a separate module which extends Exporter rather than Exporter. But there are cases where one may want to pass some configuration information to the module.

As for specifying types, that feature isn't important to me. Sometimes people want it.