Return-value for methods; seed funding

Georg Fuellen fuellen@dali.Mathematik.Uni-Bielefeld.DE
Wed, 30 Jul 1997 21:03:58 +0000 (GMT)


I'm very very grateful for your suggestions and corrections !
Keep them coming :-) (and I hope some other list-subscribers 
send some comments, too; see URL )
I'm incorporating most changes into my Master file, for the next release.
Please request this Master file before bundling the code at Stanford !

> Georg,
> > > $seq->revcom(seq($beg,$end))      returns modified object
> > > $seq->revcom($beg,$end)           same as current revcom() -- returns sequence
> > > $seq->revcom(inplace($beg,$end))  modifies the object itself -- this saves time+space
> > > 
> > > The implementation should be straightforward doing a pattern match
> > > on the argument.
> > 
> > The last sentence should read 
> > The implementation should be straightforward by setting an appropriate flag --
> > the PDL module uses inplace() in such a way, as far as I remember.
> In UnivAln, your documentation would suggest the following:
> $seq->inplace(1);
> $seq->revcom($beg,$end);
> $seq->inplace(0);
> This seems reasonable, since you could imagine having multiple 
> manipulations between the two calls to inplace().

Correct. The most luxury version could support both, however:
$seq->revcom(inplace($beg,$end)) sets the flag temporarily --
the flag is reset after the current manipulation, so that
the next manipulation will not be inplace unless specified
(the internal value of the flag could be set to 2).
$seq->inplace(1) will not be reset, so the next manipulations will be 
inplace until $seq->inplace(0) is set.
Comments ? An advantage of this, if it's extended to the q. whether
data or objects should be returned, is that there doesn't need to
be both revcom() and revcom_obj(), or get_seq() and get_seq_obj().

> As for other comments on the module, I would recommend 
> soliciting your users as much as possible. I haven't had much of a chance 
> to use it much (yet), so my input will be limited. 
> Here are a few observations:
> 1) In the "Object Manipulation" section:
>    line 69: if ($str =~ /[AaTtRr]+/) {return 1;} else {return 0;}
>   change to: 
>    line 69: if ($str =~ /[AaGgRr]+/) {return 1;} else {return 0;}
>    Similarly for line 283 (in the "Access by Selector Function" section).

Correct-- I'm happy this studid error is just in the POD, not in the code.

> 2) Also in the "Object Manipulation" section:
>    for the examples of the methods that can return a string or an array  
>    (gap_free_sites, reverse, complement, revcom), it would be clearer to 
>    have something like:
>    @alnSlice OR $alnString = $aln->reverse(1,3);
>    @alnSlice OR $alnString = $aln->complement(1,3);
>    etc...
>    It's not valid Perl but this is obvious and it gets the idea across.

Not sure. I'm now leaning towards
@alnSlice  = $aln->reverse(1,3);
$alnString = $aln->reverse(1,3);

> 3) Wording change on line 740 (in the Appendix):
>    'considered possibly dangerous' --> 'intended for internal use only'

I changed this in the Master file.

> 4) When we decide on the best way to handle how reverse/complement/revcom 
>    are to deal with slices, it would be nice for PreSeq and UnivAln to 
>    employ the same strategy.
> That's all for now. I too must sleep |^)

Have a good night :-)

> SteveC