On Mon, Feb 26, 2007 at 18:22:21 +0100, demerphq wrote: > I am. Actually my view is that using ref at all unless you control the > input is an error.
Code like Data::Visitor does not need to be as low-level-true as e.g. Data::Dump::Streamer, but still has to polymorphically handle objects, refs and non refs. That's a valid case, IMHO. > Too many times ive bumped into dumbass code that does > > if (ref($ob) == 'ARRAY') {...} > > so that i cant pass an object into the routine, for no good reason at all. That's not good code, but it's wrong for other reasons > Likewise with ref in boolean context, I almost never want the object > to be able to lie to me. But if it has to work hard to lie, then does it matter? > Well i am biased in that ive spent a ton of time on data serialization > modules where i never want to be lied to. Right, in that specific case treating the return value from ref as a boolean is an error, but in "standard" code"? > If i dont care what the object is or whether they passed in an object > then i wont test for it at all. > > Turning this around for a moment, when does it make sense to use ref > and yet at the same time not care that it might lie? Like yours, most of my code that shouldn't care at all what the value wouldn't contain a ref() or blessed() anywhere... But there is code in between serializer level omniscience and generic code level indifference - there's lots of code that needs to care a little bit in order to be more flexible, not less. I can post examples of what I mean if you like. -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418
pgpNy7KmpcDAD.pgp
Description: PGP signature