cloning and Storable Re: [Bioperl-l] bugs on branch; tests on main trunk

[lehvasla at ebi.ac.uk]

This is the best suggestion so far. Bio::Root Clonable it will be.

   -Heikki

> I don't want to see clone() placed in Bio::Root::Root, because as Ewan
> says it
> is not guaranteed to work in all cases, and will probably break at the
> worst
> time.  Also, I tend to use non-hashed implementations such as blessed
> arrayrefs and flyweights that will break generic cloning code that expects
> a
> hashref.  I don't mind seeing it placed into a util class that can be
> multiply-inherited by a subclass that needs the functionality:
>
> 	package Bio::Root::Cloneable;
> 	sub clone {
> 		my $self = shift;
> 		my %copy = %$self;
> 		return bless \%copy,ref $self;
> 	}
>
> 	...
>
> 	package NaiveSubclass;
> 	@ISA = qw(Bio::Root::Root Bio::Root::Cloneable);
>
> 	...
> 	package SomethingElse;
> 	sub do_something_that_needs_cloning {
> 		my $self = shift;
> 		my $obj  = shift;
> 		if ($obj->can('clone')) {
> 		}
> 		else {
> 			$self->throw('passed an unclonable object');
> 		}
> 	}
>
> Lincoln
>
> On Thursday 04 September 2003 03:53 am, Ewan Birney wrote:
>> On Wed, 3 Sep 2003, Heikki Lehvaslaiho wrote:
>> > I've removed the dependency for Storable. Storable is still used if it
>> > is installed. Local code can clone everything except circular
>> > references. If someone knows how to do it, I'd be happy to receive
>> help.
>> > Not having it here does not really matter because the the main use of
>> > the clone method is to allow in-memory creation of a new enzyme based
>> on
>> > an existing one.
>> >
>> > The clone code is written in very general way and should be able to
>> deep
>> > copy any in-memory objects. If you need to add a clone method your own
>> > classes, copy from there. Ewan feels strongly that deep cloning is too
>> > prone to errors to be a general property of bioperl objects, so better
>> > not add this into Bio::Root::Root, although it would be handy.
>>
>> I am willing to be overruled if there are alot of people who agree with
>> Heikki, but clone() methods are, in my view, just promise something (the
>> ability to correctly make a independent copy of all connected objects)
>> without being able to deliver.
>>
>>
>> The problem is with objects that either have eccentric memory layouts
>> (such as bound XS code; not that we have many of these) or have implicit
>> singleton style characteristics (eg, adaptors to databases which have
>> session information). a clone() which naively attempts to just in-memory
>> copy everything with truely fall over on teh first case and probably
>> cause
>> a complex problem on the second case. Remember that these objects may
>> not
>> be the top level ones, but rather be held onto in the object graph.
>>
>>
>> Furthermore, I rarely see the need for clone; in most systems just
>> reference passing is fine, and clone() is at best used as a shorthand
>> for
>> a specific constructor, (which is what it is doing in restriction
>> enzyme)
>> where I would argue the "full memory copy" is really a shorthand for
>> "build me a new RE with precisely the same attributes" which can then be
>> modified.
>>
>>
>> So, I would argue that clone() on RE's is better written as a type of
>> new option
>>
>>   $new_re = new RestrictionEnzyme ( -template => $old_re);
>>
>>
>> and we don't have clone on the Root::Object. Current Heikki is swayed
>> enough by this argument to keep the clone() method specific to RE's.
>>
>>
>> If Jason/Lincoln/Hilmar all (or mostly...) liked clone() on the Root
>> object then I'd have to conceed
>>
>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at portal.open-bio.org
>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>
> --
> ========================================================================
> Lincoln D. Stein                           Cold Spring Harbor Laboratory
> lstein at cshl.org			                  Cold Spring Harbor, NY
> ========================================================================
>
>