* Johan Vromans <jvrom...@squirrel.nl> [2010-09-13 08:05]: > Aristotle Pagaltzis <pagalt...@gmx.de> writes: > > >You don’t want to reach inside an object just because it > >happens to be hash-based. > > Interesting. For Getopt::Long (that can take an optional > hashref as its first argument) I got explicit requests from > users to allow hash based objects as well.
Don’t miss the crucial “just” in there. You may very well want to reach inside a hash-based object. Just by looking at the reftype you can’t know whether you’re supposed to, though. * David Cantrell <da...@cantrell.org.uk> [2010-09-13 15:40]: > To say that you shouldn't if you're passed a hash-based object > smacks of stupid parroting of religious dogma. It smacks of separation of concerns. What if you can take either a hashref or a path as a string, and someone happens to pass you a Path::Class object? You detect that it’s a reference, and it’s a hash. So you reach inside and end up doing something completely different from what the caller meant you to. Whoops. Or you try to code explicit checks for all the relevant permutations of tie, string overloads, hash deref overload, and a dozen other things. And/or maybe you add magic support for some popular modules like Path::Class. Or you just say `'HASH' eq ref $foo` and defer the problem to the object behind `$foo`, which can use UNIVERSAL::ref to declare its intent. And then things do exactly what you mean them to, in many more situations than before. > However, the best way to see if what you've been passed is > a hashref is to try de-referencing it, not to use isa()). That is OKish. Unfortunately it also breaks any caller who is `each`ing through any hash you are passed. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
