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

[Steven E. Brenner]

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

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.

Steve