"I understand now what's happening, ..."
That's great. In "Re^6: require() @INC hooks problem [non-Moose]", I wrote: "The mechanism behind this is a mystery to me. Why is it calling the subroutine with all the previous CODEREF values then the newly created CODEREF?" Perhaps you would share your understanding.
"... but I have trouble getting what your intention is... (???)"
The subclasses, in this instance, are to be used for exception objects. There are multiple ways to handle this; this seemed like a handy way to do it. It follows the DRY principle and abstracts any required code to a single statement.
"Why are you installing multiple hooks?"
That's not actually a requirement at the present; although, I can see that it might be useful as code development progresses. The problem (1st hook working; 2nd hook not working) came up while testing. I don't like loose ends, or sweeping problems under the carpet, so I followed up with an investigation into this.
"Why do you even need a hook if your require happens right away?"
Technically, it's not a requirement; it's just, as I said above, "a handy way to do it". I don't need to write individual X/Y/Z.pm modules for require X::Y::Z statements.
"I'm puzzled ..."
Hopefully, less so now. :-)
— Ken
In reply to Re^2: require() @INC hooks problem
by kcott
in thread require() @INC hooks problem
by kcott
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |