Interesting WTDI

[leriksen]

There is a wisdom that states "If you want to be a great coder, read great code" - in other words, learn from those who have come before. In perl, this can be done quite easily by rummaging around in the catacombs of the Monastery, or by skulking around inside CPAN.

When you start doing this, I think one of the most striking thing is just how many WTDI (Ways To Do It - from TMTOWTDI) some modules employ. Some of my favourites are

• Net::LDAP::Constant parses its own POD to set the constants it provides - key code is roughly

  while (<DATA>) { # get a line of POD
    if (/^=item\s+(LDAP_\S+)\s+\((.*)\)/) {# look for a POD line of =ite
  +m LDAP_<constant> (<value>)
      $const{$name} = sub () { $value }; # set the constant from what wa
  +s in the POD !!!
    }
  }
  

  
  Talk about keeping the code and docs in sync - the code IS the doco
• When running 'make test' for Devel::Cover, it eval's running its own test harness, captures the output, compares it to a set of 'golden' files, which contain its own test output from someone elses machine, for every recent release of perl, to see if your perl works the same as theirs - if so, you pass !!
• Test::MockObject (my new lust module - use Test::MockObject qw(schwing);)
  The method fake_module() contains the most crystal clear example of populating @INC and the symbol table I have ever seen - just beautiful - key code is roughly

  sub fake_module
  {
          my ($class, $modname, %subs) = @_; # replace methods  in $modn
  +ame with those in %subs
          $INC{ $modname . '.pm' } = 1; # pretend we have already loaded
  + the module
   
          foreach my $sub (keys %subs) { # for each implementation provi
  +ded ...
                  *{ $module . '::' . $sub } = $subs{ $sub }; # store th
  +e provided implementation in the symbol table
          }
  }
  

Those are just three recent ones where I suddenly stopped reading, sat up and went 'Thats ... incredible'.

Perhaps other monks would care to share the wonderful ideas (and weird ones too ... ) held in CPAN.

[nimdokk]

Don't have any interesting ways of doing things but I'm definitly going to take a look at the way that POD is handled in the Net::LDAP::Constant that you describe and see if its something I might be able to incorporate into the code library we have here where I work (home-grown module).

[itub]

I think Pod::Constants provides another way of extracting constants from the POD.

[nimdokk]

I'll keep that in mind, thanks.

[monoxide]

Hmmm... I have no jewels of wisdom, but i was just wondering...

Would it be possible to create/implement your own namespaces by using similar code to the Test::MockObject which is provided above? Kind of like, (guessing here...)

$INC{"MyModule.pm"} = 1; # "load" module
*{"MyModule::TestSub"} = /&TestSub; # "load" a method

Would that be correct?

[Jenda]

$INC{"MyModule.pm"} = 1; # "load" module
*MyModule::TestSub = \&TestSub; # "load" a method

[chromatic]

You only need to set a key in %INC if you want to prevent use or require from attempting to load a module from disk. (You could also put a coderef in @INC, but this way is a lot simpler.