Re: Module Style and Usage

Hi. You're right that option 3 is poor from a documentation point of view — the person reading the main script and encountering the timestamp function can't see where it's defined.

But you don't have to go as far as option 2 and fully qualify the name every time. Just change the use statement to:

use MyModule qw<timestamp>;
[download]

and then it's clear exactly where that function is coming from.

Smylers

Comment on Re: Module Style and Usage Download Code

Replies are listed 'Best First'.
Re^2: Module Style and Usage by Tanktalus (Canon) on Sep 07, 2005 at 14:30 UTC
Side note: just because you can't see where it's coming from isn't always a bad thing. It makes it easier to adjust the behaviour. Option 1: Say you have a MyModule with timestamp in it. Now a new corporate standard says all company-owned modules should be in the Example namespace. All you need to do is change the modules themselves (including moving them to the Example subdirectory) and the "use" statements. The rest of the code will work as-is. (This is also a reason to use __PACKAGE__ when referring to one's own package rather than hardcoding the name again and again - the other reason is to aid in cut&paste from module to module.) Option 2: Say you're using CPANModule's timestamp. And you find a bug. So you go write MyCPANModule, reimplementing a timestamp that works, and all you need to do is change the use statement. You don't need to go changing all the code. Option 3: Say you're using CPANModule's foo function. Which calls CPANModule2's timestamp - which is broken or just not working quite the way you want it to. If CPANModule is calling "timestamp" rather than "CPANModule2::timestamp", then you can just "use CPANModule" and then play with the symbol table and "import" your own timestamp function into CPANModule's namespace with whatever modifications you want, which will overwrite the import from CPANModule2 since the import from CPANModule2 will happen during compilation and yours will happen during runtime. (Technically, it could be during compilation as well, but after the compilation of CPANModule and thus also after compilation of CPANModule2.) Part of the idea of not naming your namespaces is to allow perl to actually Do What You Mean. Even if it's not your code ;-)	[reply]

Replies are listed 'Best First'.

Re^2: Module Style and Usage
by Tanktalus (Canon) on Sep 07, 2005 at 14:30 UTC

Side note: just because you can't see where it's coming from isn't always a bad thing. It makes it easier to adjust the behaviour.

Option 1: Say you have a MyModule with timestamp in it. Now a new corporate standard says all company-owned modules should be in the Example namespace. All you need to do is change the modules themselves (including moving them to the Example subdirectory) and the "use" statements. The rest of the code will work as-is. (This is also a reason to use __PACKAGE__ when referring to one's own package rather than hardcoding the name again and again - the other reason is to aid in cut&paste from module to module.)

Option 2: Say you're using CPANModule's timestamp. And you find a bug. So you go write MyCPANModule, reimplementing a timestamp that works, and all you need to do is change the use statement. You don't need to go changing all the code.

Option 3: Say you're using CPANModule's foo function. Which calls CPANModule2's timestamp - which is broken or just not working quite the way you want it to. If CPANModule is calling "timestamp" rather than "CPANModule2::timestamp", then you can just "use CPANModule" and then play with the symbol table and "import" your own timestamp function into CPANModule's namespace with whatever modifications you want, which will overwrite the import from CPANModule2 since the import from CPANModule2 will happen during compilation and yours will happen during runtime. (Technically, it could be during compilation as well, but after the compilation of CPANModule and thus also after compilation of CPANModule2.)

Part of the idea of not naming your namespaces is to allow perl to actually Do What You Mean. Even if it's not your code ;-)

[reply]