I don't think it wouldn't in this instance. We're tracking bug that's due to a naughty subclass breaking encapsulation (direct hash access rather than via methods).
Adding assertions to the base class won't help. That's not where the bug is.
Adding assertions to the subclasses is basically what we're doing - but at runtime not compile time.
The "problem" with perl is that because we don't have proper encapsulation we would have to add the assertions by hand to anything that might fiddle with a Foo object in a naughty manner. Doing this by hand would be a complete PITA. Doing it programmatically using Hook::LexWrap is a breeze.
I've got it - you are right. I had a thread about code analyzis - TIMTOWDTDI, obfu and analyzis of code it seems this could be applicable here too. The difference is this would be a static method while your's is a dynamic one.
Every time you add a line of code, you have a non-zero (and often deceptively large) chance of introducing a bug. Let's say that you're a really good programmer and your error rate for development is 1 bug for every 20 lines of code*. If you add 100 assertions to find one bug (assuming that Foo is used in 100 places), then you just (potentially) added another five bugs, just as hard to track. (Possibly harder, because everyone assumes that bugfix code isn't buggy.)
In addition, you now have a maintenance nightmare. Let's say that I'm your maintenance programmer. I go in and realize I need to now modify Foo somewhere. I have 24 hours to get this bug fixed. I don't know about your assertions thing. All I know is that I can fix the bug by hacking at your pretty object. Boom! Your entire assertions framework fails.
Using Hook::LexWrap (and similar techniques) is vastly preferable to adding assertions by hand, for just these reasons.
* Error rates gleaned from Code Complete on p. 610. Steve McConnell says that delivered code generally has 15-50 defects per 1000 lines. He also says that the Apps Division at MS has 10-20/1000 during in-house testing and 0.5/1000 in released code. That's a 30-1 ratio between development and release for a stringent regime. A lax regime will probably have a 10-1 ratio. Thus, a standard programmer during development will probably have 350-500 defects per 1000 lines of code. A really good one will be at 50/1000, or 1/20 lines of code.
------ We are the carpenters and bricklayers of the Information Age.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.