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

Hilmar Lapp hlapp@gnf.org
Thu, 14 Nov 2002 14:35:50 -0800


> -----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