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

[Lincoln Stein]

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
========================================================================