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
-
proposed pragma/module 'ensure' -- guidance sought re name
by Chris Hall