Parameter validation is also one of the bottlenecks when it comes to using DateTime. I personally don't believe that removing Params::Validate would make an application run faster, but at least I could silence some of the nagging that I get when I recommend DateTime to others.
Would it be worthwhile to create a P::V free version of datetime in the repo and see what it gets up? --d 2010/9/8 Michael G Schwern <schw...@pobox.com>: > On 2010.9.7 8:33 AM, Maxim Yemelyanov wrote: >> i'm writing concerning an annoying feature of DateTime - parameters >> validation. >> with >> use bigint >> in effect, DateTime croaks because ints are no longer scalars, but rather >> hashrefs. >> the module uses Params::Validate and expects most of its arguments to be of >> type SCALAR. >> i guess it makes sence to either allow the to also be OBJECTS, or, more >> precisely, its refs to equal 'bigint'. >> can someone fix this or i'd better send a patch? > > If you want to take it to the next level, Params::Validate generally ignores > the idea of overloading. Part of the point of overloading is to fool > interfaces into accepting objects, so it defeats the point if you have > something that goes around blowing their cover. I'd say that SCALAR should > quietly accept a string or numeric overloaded object. > > You can detect numeric overloading by checking overload::Method($obj, q[0+]). > String with q[""]. Since Params::Validate doesn't distinguish between > strings and numbers, you'd have SCALAR check for either. Like: > > blessed($thing) && > (overload::Method($thing, q[0+]) || overload::Method($thing, q[""])); > > For bonus points, do ARRAYREF, HASHREF and BOOLEAN. > > > -- > A: Yes. >> Q: Are you sure? >>> A: Because it reverses the logical flow of conversation. >>>> Q: Why is top posting annoying in email? >
