But you only know whether something is wrong if you actually peek in the code of the parent class1. But that means breaking encapsulation2, which you aren't supposed to do when doing OO.
I would leave in the bless. At worst, it's redundant. At best, it fixes something the parent does wrong.
1 And keep peeking. If it's ok now, it may no longer be ok tomorrow after the sysadmin upgraded some packages.
2 Of course, the code of the OP already assumes the parents constructor returns a hashref. So the OP has already sacrificed one the pearls of OO already. | [reply] |
But you only know whether something is wrong if you actually peek in the code of the parent class
No, no peeking necessary. I have no idea what you're talking about.
At worst, it's redundant.
It's usually redundant, but it's not the worst case. At worse, the parent (and thus the child) malfunctions (obviously or subtly).
At best, it fixes something the parent does wrong.
At best, it's a workaround for a bug in the parent? If there's a bug in the parent, fix the parent. Don't use a workaround just in case you might need it.
| [reply] |
If there's a bug in the parent, fix the parent.
That assumes you control the parent.
| [reply] |