[Bioperl-l] $obj->clone

[Hilmar Lapp]

On Wednesday, September 18, 2002, at 03:59 PM, Ewan Birney wrote:
>
> On Wed, 18 Sep 2002, Hilmar Lapp wrote:
>
>> This was on the table a while ago, I know, so it may be a dead horse
>> I'm beating. I rather mean it as a poll what people think and
>> whether people think life is going to be easier or unchanged w/ or
>> w/o a clone method.
>>
>> The background why I resumed beating this horse is I have written
>> some code for bioperl-db that deep-traverses objects and replaces
>> all possible child objects. This would get me 3/4 of the way for
>> writing up a deep-clone routine (shallow clone is 2 lines in perl).
>>
>> Any thoughts whether having this would be useful or rather dangerous?
>
> I have to admit my knee jerk reaction is "dangerous".
>
> What is the use case for this and are you sure it is senseible?
>
>
> (not so against it... just..... worried about consequences)
>

I know, my knee jerk reaction also has been "dangerous." I just 
can't give something tangible why it would actually be dangerous, or 
in which situation. Can you? (I'm just wondering whether this being 
dangerous is more a myth than a fact.)

To give you an example where I'm currently deep-cloning an object 
(but not generically, which in fact _is_ dangerous, because it may 
break inheriting classes): I'm expanding ChrisM's BioQuery class to 
really represent object-level queries. Then I added a method 
BioQuery::translate_query() that translates the object-level query 
to a relational model-query (that can be fed to a SQL renderer). It 
clones $self and then modifies the clone, so that the original 
BioQuery remains untouched and can always be used again.

Something more bioperl'istic: PrimarySeqI::trunc() and revcomp(). If 
we ignore for a second that you need to translate feature 
coordinates (and for trunc() possibly prune features), essentially 
you want these methods to return deep-cloned objects (with seq() etc 
changed of course).

Xiaoying, you sent me a message you're all for it. What sort of use 
case would that solve for you, if it's different from the ones I 
mentioned?

	-hilmar

--
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------