package MyCGI;
use base qw(CGI);
use POSIX qw(access);
MyCGI-> new();
Today there's no such thing as CGI::access, so we're safe. Tomorrow, next version of CGI.pm might introduce internal "sub access" that is supposed to be called from new(), but in the code above, it mysteriously wouldn't. | [reply]
[d/l] |
Yes sure, I see what you mean, but I think you're kinda mixing two separate issues here — so it
wasn't immediately clear to me, with which you wanted help.
For one, there's the question of how to avoid to inadvertendly
import stuff into your namespace that might clash with something else
(this is what I tried to answer).
Then, there's the problem of accidentally introducing something in the
inheritance hierarchy which does interfere with the so far established
lookup mechanics in the code. For the latter problem it's irrelevant whether you
import access from POSIX, or whether you yourself happen to write
a new routine MyCGI::access. If it's found first along the
inheritance chain for a certain type of object, it will be called -
that's it. I don't think there's much you can do to prevent this from
possibly happening within the standard Perl5 OO framework.
OTOH, I have to say that I personally cannot remember to have ever
encountered that type of problem in practice within the last decade of my
programming in Perl5 (and I've used quite a number of modules during
that time). But maybe I just don't recall the incidence, because it was
trivial to diagnose and fix... Dunno.
| [reply]
[d/l]
[select] |