Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

chromatic wrote: > On Thursday 01 March 2007 17:46, Adam Kennedy wrote: > >> Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to >> remember that at one point it was considered the only valid use of >> UNVERSAL::can directly. > > That's the only case I can think of too. Hmm, that's

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

* Adam Kennedy <[EMAIL PROTECTED]> [2007-03-02 03:05]: > This will hopefully clear up the Module::Build bootstrap > problem and remote the need for Module::Install altogether > (other than as syntactic sugar). Best Perl-related news I’ve seen in a while. Regards, -- Aristotle Pagaltzis //

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On Thursday 01 March 2007 17:52, Adam Kennedy wrote: > As much as I dislike UNIVERSAL::, I'd FAR prefer to have it all > maintained by one person. > > That way I can submit my typically evil bugs in Test::MockObject and > have chromatic do whatever is needed across all the modules to make it > wor

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On Thursday 01 March 2007 17:46, Adam Kennedy wrote: > Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to > remember that at one point it was considered the only valid use of > UNVERSAL::can directly. That's the only case I can think of too. -- c

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

chromatic wrote: 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

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

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. As much as I dislike UNIVERSAL::, I'd FAR prefer to have it all maintained by one person. That way I can submit my typically

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

Yuval Kogman wrote: BTW, pure perl blessed() will work: sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) } sub blessed ($) { local($@, $SIG{__DIE__}, $SIG{__WARN__}); length(ref($_[0])) ? eval { $_[0]->a_sub_not_likely_to_be_here }

Re: Object Identification Cold War and the return of autobox.pm (wasRe: UNIVERSAL::ref might make ref( $mocked_obj ) sane)

Adam Kennedy wrote: >> IT SHOULD NOT BE THIS COMPLICATED TO IDENTIFY THE HERITAGE OF AN OBJECT! > > use Params::Util '_INSTANCE'; > > if ( _INSTANCE($obj, 'Whatever') ) { > > } Oh good, depend on another module to implement a basic language feature. (I appreciate your suggestion but I'm LAMENT

Re: Object Identification Cold War and the return of autobox.pm (was Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane)

chromatic wrote: 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. I think the problem he's refering to is that if the ca

Re: Object Identification Cold War and the return of autobox.pm (wasRe: UNIVERSAL::ref might make ref( $mocked_obj ) sane)

Michael G Schwern wrote: 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.

Re: Module proposal: Syslog::DevKit

Brad Lhotsky wrote: I'm in the process of implementing a large scale central syslog architecture based on syslog-ng and POE. syslog-ng buys me compliance while I finish building my custom correlation engine with POE. If you're trying to implement a syslog server in POE, did you take a look

Re: Unit vs. use case/functional testing

On 3/1/07 1:05 PM, "Eric Wilhelm" <[EMAIL PROTECTED]> wrote: >> although it's taken care of by a module >> that we can assume is fully tested (details will be forthcoming at >> some point, methinks). > > I would like to see that. Please keep us posted. Will do, it'll be on CPAN, although I'm no

Re: Unit vs. use case/functional testing

On 3/1/07 1:42 PM, "chromatic" <[EMAIL PROTECTED]> wrote: > On Thursday 01 March 2007 10:36, Andy Armstrong wrote: > >> If you get it right it'll also be a great help to the people writing >> the rules. You can give them a tool which allows them to start with >> an assertion and work backwards to

Re: ExtUtils::MakeMaker: Including binary files?

Florian Scharinger wrote: > Hi, > > I'm trying to get MakeMaker to create a Makefile for me which should do > the following, but I fail in one part: > > * Put my Perl modules to $prefix/sbin Uhh, Perl modules in sbin? You sure? > * Put my Perl script to $prefix/sbin as well > * Put some bin

ExtUtils::MakeMaker: Including binary files?

Hi, I'm trying to get MakeMaker to create a Makefile for me which should do the following, but I fail in one part: * Put my Perl modules to $prefix/sbin * Put my Perl script to $prefix/sbin as well * Put some binary file to $prefix/bin The last step doesn't work since the binary files end

Re: Unit vs. use case/functional testing

On Thursday 01 March 2007 10:36, Andy Armstrong wrote: > In addition to the benefits of test coverage you're being persuaded > to decouple components from one another so they can be used both for > testing and in the application - which is in general a good thing. > > If you get it right it'll als

Re: Unit vs. use case/functional testing

On 1 Mar 2007, at 18:15, Andrew Gianni wrote: To test the rules you could maybe extend the rule notation to allow assertions to be expressed as part of the rule set and write a test harness that uses your (now proved) rules engine to test the assertions. That's sort of what I was thinking. Th

Re: Unit vs. use case/functional testing

On 3/1/07 12:18 PM, "Andy Armstrong" <[EMAIL PROTECTED]> wrote: > To test the rules you could maybe extend the rule notation to allow > assertions to be expressed as part of the rule set and write a test > harness that uses your (now proved) rules engine to test the assertions. That's sort of wha

Re: Unit vs. use case/functional testing

# from Andrew Gianni # on Thursday 01 March 2007 08:42 am: >However, our business rules >have gotten complicated enough that we are no longer writing them that > way explicitly in the code. In the last application we built, we put > the rules in a database and the appropriate ones were pulled base

Re: Unit vs. use case/functional testing

On 1 Mar 2007, at 16:42, Andrew Gianni wrote: Any insight appreciated. Recommendations on good books on general testing philosophy would also be helpful (I've already got the developer's notebook). It sounds as if you have two distinct things to test. You have a rules engine that has to cor

Unit vs. use case/functional testing

We're starting to write some rather complex business applications that include a lot of business rules and I've come up against a bit of a conundrum: how to best test things that aren't unit-testable. Let me explain. We've gotten rather efficient at writing unit tests, using Devel::Cover (understa

Re: Custom extensions to META.yml

On 3/1/07, David Golden <[EMAIL PROTECTED]> wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in