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:
> $myseqcopy = $myseq->copy;
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:
> 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
> 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.