in reply to Re: (tye)Re4: ref, no, maybe?
in thread ref, no, maybe?
"I object! Your honor, to use the 'It's documented so it isn't a bug' defense, the defendant also has to document why the 'bug' wasn't just 'fixed'." ;-)
So do you write "I'm too lazy to use UNIVERSAL::isa() -- too many keystrokes"? "I have a religious and/or philosophical objection to object implementations using my module"?
If your documentation says "hash ref" and not "hash ref that isn't blessed", then not handling a "blessed hash ref" (which is, by the way, still a "hash ref") is a violation of your own documentation. q-:
If your documentation says "an unblessed hash ref", then I have to ask "Why??". Are you now going to start checking tied(%$self) and croaking if the reference is to a tied hash? Is there some problem with using UNIVERSAL::isa()? A very simple change makes your module more useful. Is there some down side to this? I don't see one. I didn't see you mention one. What is your objection to this?
And there are other cases that your theoretical module "breaks". For example, Win32::TieRegistry exposes the Win32 "Registry" as a huge hash of hashes. So the majority of things that you'd want to do can be done by just dealing with a huge hash of hashes. But for a few advanced options, the reference to this huge virtual hash of hashes is also blessed into a package so you can use it directly to make method calls.
So it really sucks when a module, for example, to search down a hash of hashes searching for something (kind of like File::Find for hash trees) can't be used on this hash of hashes that I did all this work to make available to millions of Win32 Perl users.
There you made me say it. Happy now?
- tye (but my friends call me "Tye")
|
---|