Reverse Complement utility, Bio::Alg, return value problem

Steven E. Brenner
Thu, 7 Aug 1997 13:58:47 -0700 (PDT)

> I would favor returning an object. As Georg states, it is more intuitive 
> and much less awkward from an OO point of view. This way it is always 
> clear when you are dealing with an object or a string:
> $myseq->revcom($beg,$end)->get_seq();
> vs.
> $myseqcopy = $myseq->copy;
> $myseqcopy->inplace(0);
> $myseqcopy->revcom($beg,$end);
> $myseqcopy->inplace(1);
> Ugh!

Good point.  I like it.

> Regarding the issue of methods that modify an existing object, 
> I would argue that such methods should be flagged with a "set" prefix so   
> it is absolutely clear what is being done: 
> $myseq->set_revcom($beg,$end);  
> would change the sequence object into its reverse complement. It could 
> also return the altered object, too.
> The advantages I see would be:
> 1) One method call replaces three; set_revcom() would call inplace() for 
>    you. 
> 2) Objects are less likely to be inadvertantly altered (or not altered) 
>    due to a missplaced or incorrect inplace() call. Requiring calls to 
>    inplace(1) and inplace(0) forces the client to do the accounting and 
>    thus can lead to a new class of bugs and maintenance headaches.
> A disadvantage would be having two methods (set_revcom() and revcom()) 
> instead of one, which you would need to have for every accessor. 
> But this is more in line with OO design. The inplace() calls would still 
> be useful when performing complex, multi-step manipulations.  

Another disadvantage is extra typing for the potentially more common

However, again, I agree with you.  I think that this is most likely to do
the right thing in most cases.

Question: do you propose that set_revcom() also return the object ($self),
or should the set_* functions return the modified (or previous,
unmodified)  data?  I can see arguments for all three options.