I have to say that I wonder about validation code like this. Whats the point? You are checking the type to throw an error, but what will happen if you try to use the object without doing these checks? Remarkably, in almost every way the exact same thing will happen (under strict anyway), ie, the interpreter will throw an errror.
So just let the interpreter throw the error.
Now I can hear the peanut gallery saying "yeah but what happens if they pass in an object that is blessed into a package that has the methods im concerned about?" My answer would be, you mean you know in advance that this would be wrong? What happens if they decide to reimplement the interface in a different class structure and decide to use that?
IE, most of this type of validation just removes the flexibility of the consumer, and adds very little or nothing to the robustness of your code.
I will agree there are cases where doing checks like these properly is vital, but IMO that is usally confined to cases where you have specific handlers for different input types, not simply screen for a valid type.
Ultimately if you _do_ want to do checks like these then you should look into using Scalar::Util.
In reply to Re: How to differentiate hash reference and object reference?
by demerphq
in thread How to differentiate hash reference and object reference?
by tphyahoo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |