Following on from the talk that I gave at the London.pm technical meeting I decided to do some work on developing the module I'd created to demonstrate using Test::Builder and Test::Builder::Tester into a real module. You know. With tests and documentation and even one of those handy dandy Makefile.PL files.
Originally called Test::GetSet and since renamed to Test::Accessor it's a module that checks if an accessor method can be set to a value and return the same value. More importantly, it also checks if your module complains in the correct way when you pass bad values. Sounds simple, eh?
Well no. Considering that I could think of three different ways to signal that a method was passed an incorrect value (return undef, return false, throw an exception) and have various combinations of those to be either acceptable expected failures or unexcepted failures. Now throw in the complication that I can think of five different naming conventions for accessor methods (foo, getfoo, get_foo, foo_get, fooget.)
Darnit, this was meant to be a simple hack. The work continues.
<Trelane> my fun todo?
<dipsy> Trelane, your fun
todo is probably install slash on intranet server, gtk wrapper for
sudo, Test::GD, GD::TextImage, add things to grubstreet, read the
jabber book or patch T::P::XML::DOM documentation, write documentation
for TT and XML, write an rsync backup scripts or makepm script or tidy
up Test::Accessor and CPAN it
That's without taking into account getFoo, and then all the variants of has which is frequently used (in some circles) for boolean and/or list accessors...
Re:And there are more...
2shortplanks on 2002-03-26T16:04:47
Oh I'd forgotten that. I'll add getFoo and fooGet.
I'm not sure about has. Java peeps might be tempted to call methods is_foo isFoo too (though probably not foo_is or fooIs.)
That's a bit annoying. I can't think of any way to automatically deal with this as people might be using both has, is and get and set in the same module.
Maybe I should add a final option "automatic" where I search your namespace for methods (thought repeated calls to "can".) Main trouble with doing that is that it won't work for AUTOLOAD and I was hoping to have it be compatible with things like Class::MethodMaker (which I think uses autoload, right?)
Food for thought.
Re:And there are more...
darobin on 2002-03-26T16:58:51
Yes, "is" is definitely part of the landscape as well. "has" occurs mostly for list accessors (iow what are seens as lists/arrays in Perl, but are usually array-like objects in other languages). For instance:
$el->setChildNodes(@kids);
...
if ($el->hasChildNodes) {...}Of course, this opens the can of worms of the addFoo setters and friends... not sure you want to go there.
You might want, instead of can(), to use eval {} and see if the call works. Of course, this works on the assumption that the accessor has no nasty side-effects and that it doesn't gratuitously throw exceptions (which a getter rarely does). I guess this can be worked around by discarding the nasty-side-effects part (which would be rather unusual for a getter) and testing $@ to see if it's a custom exception or the Perl one. Setters might be a bit tougher though.
Anyway, interesting project
;-) Re:And there are more...
2shortplanks on 2002-03-26T17:13:44
You might want, instead of can(), to use eval {} and see if the call works.
Um. Remember what I'm trying to do here. Test that the accessors work or not. I can't go calling them and seeing if they work then calling them to test if they work or not;-) Re:And there are more...
darobin on 2002-03-26T18:13:21
*cough*, ummmmmm, yeah....
;-) I guess now you understand better why I hate writing tests...
