As far as I can tell, Class::MethodMaker only "does" type safety to the
extent that supplied arguments can be defined to belong to or inherit from a
specified class, but beyond that no constraints on, for example, numerical
argument ranges etc. That's probably fine in many cases, but I personally
would not implement an API using such a "helper". Actually, I haven't seen
anything in the Class::* namespace that goes beyond being a nice, but
ultimately too limiting idea.

On Thu, 04 Jan 2007 10:15:37 +0000 bix@sendu.me.uk wrote:
> aaron.j.mackey@gsk.com wrote:
> > I'm not against this at all, but let's not reinvent a
> (somewhat-standard) 
> > wheel: see Class::MethodMaker and accompanying tools.
> 
> It would certainly be possible for a module author to make use of 
> Class::MethodMaker, but from what I can see each module would have to 
> use Class::MethodMaker itself, leaving them to setup and configure it in 
> their own way, and still leaving them to handle how user arguments 
> become method values.
> 
> The primary motivation for this proposal is to provide an incredibly 
> simple and consistent way of turning user args into method values. 
> Method creation was just an added extra, implemented since the burden 
> was just a few extra lines of trivial code. I don't see any significant 
> benefit* of farming out to another class to do that simple thing, only 
> the disadvantage of adding what would be a third (true) pre-requisite 
> for Bioperl installation.
> 
> 
> >> We can have the nicer:
> >>
> >> package Bio::Tools::Run::GoodBoy;
> >> sub new {
> >>	my ($class, @args) = @_;
> >>	my $self = $class->SUPER::new(@args);
> >>
> >>	$self->_set_from_args(\@args,
> >>			      -methods => [qw(id score evalue)]);
> >>
> >>	return $self;
> >> }
> >> # methods...
> >> 1;
> 
> 
> [*] The only benefit I see is that Class::MethodMaker lets you create 
> methods for storing arrays and hashes, not just scalars. But in Bioperl 
> we don't 'like' auto-created methods, using them primarily for the 
> simple scalar get/setters needed by run-wrappers where it would be too 
> tedious to implement them all directly.
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>