[Bioperl-l] Re: Automatic generation of set and get methods

[Allen Day]

this is related to the dashed params issue i had raised in an earlier 
thread -- you can't really have method names starting with dashes, and it 
would be nice to autogenerate methods.

i think it would be nice to have a class in Bio::Root:: that either 
depended on, or provided similar function to, either Class::MakeMethods or 
Class::MethodMaker.

just my 2c.

-Allen


On Thu, 14 Nov 2002, Hilmar Lapp wrote:

> 
> 
> > -----Original Message-----
> > From: Lincoln Stein [mailto:lstein@cshl.org]
> > Sent: Thursday, November 14, 2002 12:12 PM
> > To: natg@shore.net
> > Cc: bioperl-l@bioperl.org; lstein@lsjs.org; jgrg@sanger.ac.uk
> > Subject: [Bioperl-l] Re: Automatic generation of set and get methods
> > 
> [...]
> > One problem with the code you quote from Bio::Index::Abstract 
> > is that it 
> > provides no way to unset an instance variable.  For example:
> > 
> > 	$object->foo(undef);
> > 
> > will *NOT* work, because the argument is undefined.  I 
> > consider this a 
> > misfeature.  We had a thread about this on bioperl-l mailing 
> > list a month or 
> > so ago and I'm surprised it isn't fixed by now.
> 
> Every developer is more than welcome to fix it, and fellow core people even more so.
> 
> My personal take on this is that I will not go into everyone else's code and change his/her getter/setters. For my own code I do employ both idioms. It's not that seldom that I don't want an attribute's value to be changeable to undef.
> 
> >  A better 
> > idiom is this:
> > 
> > 
> >          *$func = sub {
> > 	     my $self = shift;
> >              my $current = $self->{$field};
> >              $self->{$field} = shift if @_;
> >              return $current;
> >      }
> > 
> > This also has the advantage of preserving the semantics of 
> > simultaneous get-and-set, and is consistent with LWP and other widely used 
> > modules.  The get part returns the existing value of the field, and the set 
> > part sets the  new value.
> 
> The conclusion of said thread was that in Bioperl you should not rely on the return value of a set call. I'm not in favor of making returning the previous value a supported convention - I think it creates an unnecessary burden on code review.
> 
> > >
> > > This seems so elegant, I wonder why it's not used 
> > everywhere in BioPerl. 
> > > Is there some hidden problem?
> 
> My personal take on this is whether this is elegant or not is a matter of personal taste; to me for instance it's not. There is a risk of things becoming obfuscated to other programmers, but that's maybe my personal opinion only. I'm a strong proponent of explicit software APIs and code. I have to say that never in my programming life have I really experienced writing getter/setters to be the time-limiting factor. Overall design, writing the business logic, fixing the bugs, and writing the documentation take 98% of the whole time, not writing getter/setters. Writing those is quite boring, but it's not time consuming. YMMV though.
> 
> 	-hilmar
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>