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
