[BioPerl-l] Bio::Seq->delete_SeqFeature missing?

[Matthew Pocock]

Just to play Devil's advocate...

If I hold a handle to $oldseq somewhere in the perl VM, and then 
somewhere else call $oldseq->clone and then modify the clone, then the 
original $oldseq is unchanged. Fine.

Now, if I am a sequence editor or something, how do I interactively edit 
the sequence? There will potentialy be many handles to $oldseq lying 
arround in the GUI and event-handling code, so to keep track of all of 
these so that I can replace them I need to do lots of nasty 
book-keeping. At that point the book-keeping becomes more complicated 
(not to mention likely to introduce memory cycles) than just allowing 
objects to mutate.

You can get arround having explicit listener frameworks (which probably 
wouldn't work well in perl anyhow) by doing something like adding a 
$object->editVerion that increments every time a setter is called. That 
way, interested objects could always compare the curent value of 
editVersion with one archived a way to know if any state has changed.

Objects can be designed as immutable (which does make life easier) only 
when mutating them would make them into an entirely new instance. If you 
think of sets and sets of maps, it is the difference between mutations 
making the entity a different member of the set of all things of that 
type, and the mutation changing the return value of a map from the 
entity to some space of values (i.e. is the object state enough data to 
uniquely identify the object, or is the object reference the only 
identifying feature).

Anyway, this is all getting a bit abstract, but in my view the sequence 
reference is the unique entity in this case, not the particular data it 
contains, and making them imutable will cause tears. I guess in the 
imutable world view, all the current methods for adding and removing 
features should live on some sequence manufacturing object that you say 
stuff like $seqMaker->addfeature $seqMaker->setID 
$seqMaker->makeSequence, at which point the sequence returned is truely 
immutable. You would be able to say new seqMaker($seq) to get one that 
will start with data identical to $seq, and so on. Yuck.

Matthew

ps What is the idealigocal diference between flushing all features and 
adding back the ones you like, and removing the ones you dislike, other 
than the encapsulation?


Hilmar Lapp wrote:

> Malcolm Cook wrote:
> 
>> Hilmar & Ewan,
>> 
>> I'm converted.  Thanks for the discussion.
>> 
>> If I wanted a new Bio::Seq identical in all respects to one at hand, say
>> held in $oldseq, would I write:
>> 
>>         my $newseq = $oldseq->new;
> 
> 
> Well, you actually want
> 
>           my $newsew = $oldseq->clone();
> 
> Support for cloning has been dropped at the time of migrating from a
> heavy-weight root object to a light-weight one, figuring that there is
> little if any need for cloning.
> 
> So, yes, cloning you have to code yourself. Is there a specific reason
> you need that?
> 
> 
>> And, does flush_SeqFeature simply become the following?
>> 
>> =head2 flush_SeqFeature
>> 
>> Title   : flush_SeqFeature - THIS METHOD SEEMS MISSING FROM BIO::SEQ!
>>  Usage   : $seq->flush_SeqFeature();
>>            $seq->flush_SeqFeature();
>> 
>>  Function: Removes all features from the sequence
>> 
>>  Example :
>>  Returns : TRUE on success
>>  Args    : none
>> 
>> =cut
>> 
>> sub Bio::Seq::flush_SeqFeature {
>>   my ($self) = @_;
>>   $self->{'_as_feat'} = [];
>>   return 1;
>> }
> 
> 
> Right.
> 
> 	Hilmar