Joshua ben Jore wrote:
> On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> Is there a function that is to this as overload::StrVal is to
>> stringification?
Wouldn't that just be CORE::ref $obj ?
On 2/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Joshua ben Jore wrote:
> On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> Is there a function that is to this as overload::StrVal is to
>> stringification?
Wouldn't that just be CORE::ref $obj ?
I think Josh is doing something sor
On 24 Feb 2007, at 22:58, Michael G Schwern wrote:
Just make sure whatever you return evaluates according to the test
pass/fail
and not its value and you should be fine. You can return a little
wrapper
object like...
Or you could just return a reference to an array with the value in
it
Mark Fowler wrote:
>
> On 24 Feb 2007, at 22:58, Michael G Schwern wrote:
>
>> Just make sure whatever you return evaluates according to the test
>> pass/fail
>> and not its value and you should be fine. You can return a little
>> wrapper
>> object like...
>
> Or you could just return a referen
Yuval Kogman wrote:
> On Sun, Feb 25, 2007 at 22:34:15 -0800, chromatic wrote:
>
>> Why not, I already have half of the other stuff in UNIVERSAL
>
> Just don't tell Adam.
>
Or me. I have a personal hate relationship with MockObject in this way.
I love MockObject. I hate getting warnings abo
* Luke Closs <[EMAIL PROTECTED]> [2007-02-23 17:30]:
> On 2/23/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> >That will not call the importer in the right package.
>
> To expand on this answer, without funky voodoo, after loading
> mock::LWP::Simple perl won't think it had loaded LWP::Simple.
> So
* Michael G Schwern <[EMAIL PROTECTED]> [2007-02-25 00:00]:
> You can return a little wrapper
> object like...
>
> # I didn't actually try this
> package Test::Result;
Or use Scalar::Util::dualvar (Perl uses the string value to check
truth so the numeric value may be whatever).
Regar
On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote:
> Ick Neither ref nor blessed have never been a booleans before and
> even this doesn't change that. Ref couldn't even used to decide if you
> had an object because the two false values '' and '0' can both be
> returned by objects:
On 2/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Joshua ben Jore wrote:
> On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> Is there a function that is to this as overload::StrVal is to
>> stringification?
Wouldn't that just be CORE::ref $obj ?
No. I don't know how to solve this p
On Sun, Feb 25, 2007 at 23:55:13 -0800, chromatic wrote:
> I wonder if pulling the new DOES() code out of universal.c into a module for
> 5.9.4 and earlier would alleviate that pain somehow.
I don't know, most of the times I have an if clause trying to figure
out all the possibilities of a value
On 2/26/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote:
> Ick Neither ref nor blessed have never been a booleans before and
> even this doesn't change that. Ref couldn't even used to decide if you
> had an object because the two fals
On 2/26/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
I'm of the opinion that it is clear and blatantly an error to ever use
ref as a boolean.
One liners and minor snippets where you control the input data would
be an exception IMO.
The correct boolean is defined( blessed( obj ) ) because th
On Mon, Feb 26, 2007 at 17:47:23 +0100, demerphq wrote:
> On 2/26/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
> >I'm of the opinion that it is clear and blatantly an error to ever use
> >ref as a boolean.
>
> One liners and minor snippets where you control the input data would
> be an exception
On 2/26/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
On Mon, Feb 26, 2007 at 17:47:23 +0100, demerphq wrote:
> On 2/26/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
> >I'm of the opinion that it is clear and blatantly an error to ever use
> >ref as a boolean.
>
> One liners and minor snippets whe
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 a
On Monday 26 February 2007 06:35, Christopher H. Laco wrote:
> Or me. I have a personal hate relationship with MockObject in this way.
> I love MockObject. I hate getting warnings about 3 party modules use of
> can in my test suite.
Ideally those third parties would fix their buggy code, but afte
Hi Perl-QA group,
I am new to testing using PERL rather I am new to Perl too. And wanted to
get some pointers as far as the testing is concerned:
1) What methadology is usually used to mangae the test data/ Test scripts?
2) Is there any editor that can be used to write the Perl test script?
3)
Subject: New to Perl testing.
From: Smita Chavan <[EMAIL PROTECTED]>
Date: Mon, 26 Feb 2007 11:33:51 -0800
}1) What methadology is usually used to mangae the test data/ Test scripts?
There is no single methodology used to manage test data and test programs.
It depends on your environment, what
Yuval Kogman wrote:
>> 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?
Yeah, I'm with Yuval here. There seem to be a cold war going on here wrt
identifying an object.
In the beginning we
On Monday 26 February 2007 13:50, Michael G Schwern wrote:
> But what if isa() is broken or has side effects, hmm?
That's not the caller's problem. Fix the broken code. Don't break more code
trying to work around bugs.
That little mantra could have solved a whole lot of this mess.
> And what
On Mon, Feb 26, 2007 at 13:50:58 -0800, Michael G Schwern wrote:
> Please reconsider autobox.
While I second that for the aforementioned reasons I have an off
topic one too:
That's the only way it'd get accepted. Something that devious has to
be in core to pass off as safe.
--
Yuval Kogman <
# from Michael G Schwern
# on Monday 26 February 2007 01:50 pm:
>And then someone defined a $SIG{__DIE__} so now its C<<{ local
>$SIG{__DIE__}; eval { $obj->isa($class) } }>>
No. If that $SIG{__DIE__} doesn't check $^S, then it's just
delete($SIG{__DIE__}) and you're back to eval {$obj->isa($c
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Monday 26 February 2007 01:50 pm:
>
>> And then someone defined a $SIG{__DIE__} so now its C<<{ local
>> $SIG{__DIE__}; eval { $obj->isa($class) } }>>
>
> No. If that $SIG{__DIE__} doesn't check $^S, then it's just
> delete($SIG{__DIE__}) a
# from Michael G Schwern
# on Monday 26 February 2007 03:29 pm:
>Eric Wilhelm wrote:
>> # from Michael G Schwern
>>
>> # on Monday 26 February 2007 01:50 pm:
>>> And then someone defined a $SIG{__DIE__} so now its C<<{ local
>>> $SIG{__DIE__}; eval { $obj->isa($class) } }>>
>>
>> No. If that $SI
On 2/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Also you don't want it to always be true. You want it to reflect whether
the test passed or failed. I presume you still want the extra value even if
the test failed.
Well, at first I didn't think that I'd want it, but after seeing your
Eric Wilhelm wrote:
>> You don't want to delete someone else's $SIG{__DIE__}.
>
> No, I do. Why would anyone else's $SIG{__DIE__} be in my code? Now,
> maybe you're going to say that someone might use my module and be upset
> because their broken $SIG{__DIE__} is broken.
Yes, exactly. Especi
# from Michael G Schwern
# on Monday 26 February 2007 05:53 pm:
>Put another way... be lax in what you accept, strict in what you
>output.
That's a different subject having more to do with piped text than code
(if anybody in this case is being strict about acceptance here, it's
perl) and even
Eric Wilhelm wrote:
>> Also this:
>> eval { delete $SIG{__DIE__}; $obj->isa($class) }
>> is no shorter than this:
>> eval { local $SIG{__DIE__}; $obj->isa($class) }
>
> To be clear (since I must not be funny enough), the delete() bit was a
> joke. This is much shorter than both:
>
> eval
On Monday 26 February 2007 21:20, Michael G Schwern wrote:
> Case in point... my tests started suddenly warning about "UNIVERSAL::isa
> called as a function in Class::DBI". After spending a bunch of time trying
> to figure out what the hell was going on and if Redhat introduced some new
> warning
29 matches
Mail list logo
