sub sub1 { (caller(1))[6] =~ /(^\w+)/; print "$1 is not accessible!" }
+;;
{
no strict 'refs';
*{ 'sub' . $_ } = *sub1 for 2 .. 70;;
}
sub1;;
sub1 is not accessible!
sub70;;
sub70 is not accessible!
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
This seems to be the same problem as in Inherit only few methods from a parent class -- generating the 70 subs is the wrong way, as you were told in the very first reply.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
| [reply] |
| [reply] |
You can define an AUTOLOAD sub.
It is called in place of any undefined sub and receive in the $AUTOLOAD variable the name of the sub originally invoked. You can test $AUTOLOAD to see if it matches your naming conventions (in your example /sub\d+/).
Rule One: "Do not act incautiously when confronting a little bald wrinkly smiling man."
| [reply] |
The issue is that the subroutine is actually defined in the parent class..I need to define that in the child class just to say "This is not accessible!" . Because I am inheriting it from the Parent.. So I cant use AUTOLOAD...
| [reply] |
| [reply] |
You want to sub-class the 70 subroutines in a module that you will not / cannot use from the parent class. Whoever wrote a module that has subroutines called sub1 to sub70 deserves none of these routines to be called ever!And then you want us to believe that (as by sheer coincidence) the subroutines sub71 to sub100 are OK to be used. I don't believe that, this is a thinly disguised homework question.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] [d/l] [select] |