# from Ovid
# on Friday 20 June 2008 05:45:
>Test::Most exports 'set' and Class::Accessor calls a 'set' method.
>Oops.
>
>I'm trying to think of the best way to deal with this. My first
>thought is to create a drop in replacement for Exporter which will not
>export a function if caller->can($function) *unless* the person
>explicitly lists it in the import list with a unary plus:
Even if you could detect yet-to-be-defined subs, that wouldn't actually
fix this case, where the accident is that you have overridden the
parent's method.
Calling unimport() would fix the case where you're stomping on inherited
methods. This assumes an unimport() was defined.
Note that, should caller() define its own foo(), warnings will tell the
user about that if you have installed a foo() on their behalf. So, the
case of "direct stomping" in the same symbol table is already somewhat
covered. The dangerous-and-silent case has to do with methods and
inheritance, and can be completely solved by unimport().
--Eric
--
Moving pianos is dangerous.
Moving pianos are dangerous.
Buffalo buffalo buffalo buffalo buffalo buffalo buffalo.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
