Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[brian d foy]

In article <[EMAIL PROTECTED]>, chromatic
<[EMAIL PROTECTED]> wrote:

> On Friday 01 June 2007 10:47:00 Andy Armstrong wrote:
> 
> > You could send them to me if you fancy? I'm guessing chromatic's
> > pretty busy.
> 
> I lost most of my outstanding patches a couple of weeks ago too, and only
> just 
> noticed.

If only we had some sort of community service where we could post
patches and other people could see them :)

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-02 03:40]:
> I know it's not as cute as the current interface - but cute can
> be surprising and I don't think a surprising interface is
> necessarily a  good thing :)

Agreed. It just depended on what you preferred; in case of a
method per metric, generating methods + AUTOLOAD seemed to me to
be the simplest option, as it would involve the least amount of
conditional code.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 2 Jun 2007, at 01:25, A. Pagaltzis wrote:


* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-01 16:25]:

I could

* generate the methods dynamically based on the Kwalitee
  modules that are installed

* generate only the current methods and add a new method
  test_against() (or whatever) that provides access to any
  named Kwalitee test

* replace the generated methods with an AUTOLOAD handler

In the test_against() or AUTOLOAD scenarios I could then make
Kwalitee tests for which the module is unavailable skip
automatically.

Thoughts?


Remember you can also combine options #1 and #3: generate methods
at compile-time and use AUTOLOAD just for skipping. Would there
be any provision for catching typos in any of these cases,
though?


Well no. And that's one of the reasons why I'd like to move away from  
the method-named-after-test interface entirely. I'm thinking


* create the same methods that are currently created - for backwards  
compatibility

* deprecate that interface
* create a new interface - kwalitee('test_name', ...) which is just a  
conventional method that despatches to the

  named test.

I know it's not as cute as the current interface - but cute can be  
surprising and I don't think a surprising interface is necessarily a  
good thing :)


--
Andy Armstrong, hexten.net

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-01 16:25]:
> I could
> 
> * generate the methods dynamically based on the Kwalitee
>   modules that are installed
> 
> * generate only the current methods and add a new method
>   test_against() (or whatever) that provides access to any
>   named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make
> Kwalitee tests for which the module is unavailable skip
> automatically.
> 
> Thoughts?

Remember you can also combine options #1 and #3: generate methods
at compile-time and use AUTOLOAD just for skipping. Would there
be any provision for catching typos in any of these cases,
though?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[chromatic]

On Friday 01 June 2007 10:47:00 Andy Armstrong wrote:

> You could send them to me if you fancy? I'm guessing chromatic's
> pretty busy.

I lost most of my outstanding patches a couple of weeks ago too, and only just 
noticed.

-- c

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Thomas Klausner]

Hi!

On Fri, Jun 01, 2007 at 03:23:14PM +0100, Andy Armstrong wrote:
 
> Test::Kwalitee currently exposes the known test types as methods. I can
> make it delve into Module::CPANTS::Analyse to find the tests that are
> actually available - but then what to do about the methods?

Sorry, not a lot of time at the momemt, but I remember that somebody 
(I think  Nathan Haigh <[EMAIL PROTECTED]> ) already patched 
Test::Kwalitee to dynamically figure out which metric to use.

But I'm only following this thread with 50% attention (sorry, YAPC takes 
up all my tuits ATM), so might mix up things...


> I could
> 
> * generate the methods dynamically based on the Kwalitee modules that
>   are installed
> 
> * generate only the current methods and add a new method test_against()
>   (or whatever) that provides access to any named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
> tests for which the module is unavailable skip automatically.
> 
> Thoughts?
> 
> -- 
> Andy Armstrong, hexten.net
> 

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 1 Jun 2007, at 18:41, Nathan S. Haigh wrote:
I recently made some simple changes to Test::Kwalitee so that it  
would test all the metrics provided by Module::CPANTS::Analyse.  
However, Chromitic
hasn´t yet updated CPAN with these changes. I´m on holiday at the  
moment so I won´t be even more nerdy than I am at the moment ) 
reading my works
e-mails) by going into detail about the changes. Either Chromictic  
could get the changes through into CPAN or I can send you my  
changes on my return

from holiday!


You could send them to me if you fancy? I'm guessing chromatic's  
pretty busy.


--
Andy Armstrong, hexten.net

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Nathan S. Haigh]

Quoting Andy Armstrong <[EMAIL PROTECTED]>:

> On 1 Jun 2007, at 06:38, chromatic wrote:
> 
> > On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote:
> >> On 1 Jun 2007, at 02:09, brian d foy wrote:
> >>> I'll have some time next week if Andy doesn't beat me too it.
> >>
> >> I'm having a rummage around now :)
> >>
> >> chromatic: do you have a .perltidyrc you could send me? My muscle
> >> memory keeps reaching for the perltidy hot key that would convert
> >> your code to AndyPerl :)
> >
> > I use -ci=4 -bl these days.
> 
> Not on Test::Kwalitee you didn't :)
> 
> What's peoples' view on this?
> 
> Test::Kwalitee currently exposes the known test types as methods. I can
> make it delve into Module::CPANTS::Analyse to find the tests that are
> actually available - but then what to do about the methods?
> 
> I could
> 
> * generate the methods dynamically based on the Kwalitee modules that
>are installed
> 
> * generate only the current methods and add a new method test_against()
>(or whatever) that provides access to any named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
> tests for which the module is unavailable skip automatically.
> 
> Thoughts?
> 
> -- 
> Andy Armstrong, hexten.net
> 
> 


I recently made some simple changes to Test::Kwalitee so that it would test all 
the metrics provided by Module::CPANTS::Analyse. However, Chromitic
hasn´t yet updated CPAN with these changes. I´m on holiday at the moment so I 
won´t be even more nerdy than I am at the moment )reading my works
e-mails) by going into detail about the changes. Either Chromictic could get 
the changes through into CPAN or I can send you my changes on my return
from holiday!

Cheers
Nathan

Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 1 Jun 2007, at 06:38, chromatic wrote:


On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote:

On 1 Jun 2007, at 02:09, brian d foy wrote:

I'll have some time next week if Andy doesn't beat me too it.


I'm having a rummage around now :)

chromatic: do you have a .perltidyrc you could send me? My muscle
memory keeps reaching for the perltidy hot key that would convert
your code to AndyPerl :)


I use -ci=4 -bl these days.


Not on Test::Kwalitee you didn't :)

What's peoples' view on this?

Test::Kwalitee currently exposes the known test types as methods. I can
make it delve into Module::CPANTS::Analyse to find the tests that are
actually available - but then what to do about the methods?

I could

* generate the methods dynamically based on the Kwalitee modules that
  are installed

* generate only the current methods and add a new method test_against()
  (or whatever) that provides access to any named Kwalitee test

* replace the generated methods with an AUTOLOAD handler

In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
tests for which the module is unavailable skip automatically.

Thoughts?

--
Andy Armstrong, hexten.net