develooper Front page | perl.perl5.porters | Postings from August 2008

proposed pragma/module 'ensure' -- guidance sought re name

From:
Chris Hall
Date:
August 26, 2008 04:19
Subject:
proposed pragma/module 'ensure' -- guidance sought re name
Message ID:
SWKAvRVtY+sIFwZ9@agrotera.halldom.com

I got very tired of being bitten, at run-time (yikes!), by undefined 
subroutine errors -- either simple spellinge errors or even subroutines 
I'd not got round to writing, yet.

So...

I have a small module which scans the symbol table (in a CHECK block) 
for names with no defined part -- which generally means undefined 
subroutines.  [Sadly, a defined scalar/array/hash can mask an undefined 
subroutine of the same name -- suggestions for improvement gratefully 
received.]

Because Exporter::import generates apparently defined subroutines (and 
other stuff) for names which are exported, this pragma/module provides 
ensure::import, which checks things before passing the imports to 
Exporter::import.

Any package, including main, which uses this pragma/module is checked -- 
other packages are ignored.

Packages which 'use ensure' can 'no ensure ....' anything which is not 
expected to be defined when the checks run.

'use ensure' is a drop in replacement for 'use Exporter qw(import)'.

It also implements some extensions to import/export:

   (a) use xxx qw(:NONE) -- invokes xxx::import, but imports nothing,

   (b) use yyy qw(:ALL)  -- imports everything in @EXPORT and @EXPORT_OK

   (c) 'IMPLICIT' tag in %EXPORT_TAGS -- anything in this tag is exported
       when 'use zzz qw(foo bar ...)'.

These are not essential to the main purpose of the pragma/module, but 
fit happily because it's necessary to intercept Exporter::import.

I have prepared this for CPAN, see:

   <http://www.highwayman.com/perls/ensure-1.05.tar.gz>

I have consulted comp.lang.perl.modules.  I have been advised that:

   1. this is more a pragma than a module.

   2. that I should consult this forum on the topic of pragma and the
      naming of pragma.

So, all comments and guidance gratefully received, before I upload to 
CPAN.

------------------------------------------------------------------------

FWIW, I feel that 'use strict' could be extended to do this, and 
probably do it better.  But, in the meantime I have found this useful.

I found B::Lint.  The advantage this pragma/module has is that it lives 
permanently with each package, same like 'use strict'.  (It is also more 
limited.)

------------------------------------------------------------------------

Stuff which is expected to be satisfied by AUTOLOAD can be declared 'no 
ensure'.  I wonder if it would be possible/useful to be able to declare 
stuff which is to be AUTOLOADed and cross-check at compile-time ?

Also: sadly, this doesn't help with undefined class/object methods, 
which is a much harder problem.  I wonder whether a variable attribute, 
ie:

   my $object : CLASS ;

could be used, fairly straightforwardly, to trigger a compile-time check 
that:

   $object->bar()

can be resolved.

Mind you, I imagine that 'my $object = new CLASS ....' is so common that 
such a check could deduce the class of many objects.  But static 
analysis like this may be tricky !
-- 
Chris Hall               highwayman.com



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About