use Win32::OLE qw(in);
use Win32::OLE::Const 'Microsoft Word';

sub print_tables {
    my $word =Win32::OLE->new('Word.Application','Quit');  # shift;
 
    my $word_file = file(abs_path(shift));
 
    my $doc = $word->{Documents}->Open("$word_file");
    my $tables = $word->ActiveDocument->{Tables};
 

 

    for my $table (in $tables) {
my $numrows=$table->Rows->Count; 
 
my $rownum=1;
 while($rownum<=$table->Rows->Count){
...
 $main::numcols=$table->Columns->Count;
my $cell5=$table->Cell($rownum,$main::numcols);#this is the last colum
+n
.....
                                     }


                               }  
  }
[download]

$password= secret(...);
...
local $password->{stringify_mask}= undef if ref($password) eq 'Crypt::
+SecretBuffer';
$db= DBI->connect($dsn, $user, $password, \%attr);
[download]

On Github, robrwo [suggested a new more functional-programming-like API, namely that a method of SecretBuffer would pass the secret to a callback. My thought on the matter was that the *real* missing feature is a duck-typing API that doesn't need to be specific to SecretBuffer, which should provide an easy and convenient recipe for code that doesn't have a hard dependency on SecretBuffer to gain access to secrets.

I'd like to conduct an informal poll of which design people like the best:

1. "apply", a method which takes a callback of one argument:

   if ($password isa 'Crypt::SecretBuffer') {
     $db= $password->apply(sub { DBI->connect($dsn, $user, $_[0], \%attr)
   + });
   else {
     $db= DBI->connect($dsn, $user, $password, \%attr);
   }
   [download]

2. A more distinct method name that could be used for duck-typing and apply to other types of object:

   if (blessed $password && $password->can("unmask_secret_to")) {
     $db= $password->unmask_secret_to(\&DBI::connect, 'DBI', $dsn, $user,
   + $password, \%attr);
   } else {
     $db= DBI->connect($dsn, $user, $password, \%attr);
   }
   [download]

   1. reveal_secret_to
   2. unmask_secret_to
   3. call_with_secret
   4. call_unmasked
3. Use a scalar-ref overload:

   $db= DBI->connect($dsn, $user, ref $password? $$password : $password, 
   +\%attr);
   [download]

I just came up with that scalar-ref idea, and seems pretty safe because no code would normally scalar-dereference a ref unless the ref type was 'SCALAR'. Still, that's drastically lowering the bar for leaking the secret, and isn't advertising that it has this capability...

While pondering your preference, also consider the question "If someone contributed a patch to a module I maintain that added support for receiving secrets via SecretBuffer, how much boilerplate would I be willing to accept?"