[Bioperl-l] is_remote() in Location::Simple

[Jason Stajich]

On Tue, 1 May 2001, Hilmar Lapp wrote:

> Elia Stupka wrote:
> > 
> > > This was my feeling: the utility of this method is tied to some
> > > quite specific application and not intuitive anywhere else (a
> > 
> > I see your point, however the specific application is another bioperl
> > module, bioperl-db and in biopeerl-db we don't want to do carry the main
> > seqid through many objects, do you have any proposal to solve this?
> > 
> > I see one simple option, to reimplement is_remote becomes something like
> > _is_remote_in_parser, which should make us all happy, how does it sound?
> > Other suggestions?
> > 
> 
> It appears that the concept of parent sequences in terms of locations
> applies to sub-locations of a compound (split) location, the issue
> being that if such a sub-location is a simple location there is no way
> of tracking the parent in the sub-location. Is this correct?
> 
> If it is, my suggestion is the following (code obviously slightly
> simplified):
> 
> package Bio::Location::SubLocationI;
> @ISA = qw(Bio::LocationI);
> 
> sub parent_seq_id {
> 	# abstract stub
> }
> 
> package Bio::Location::SimpleSubLocation;
> @ISA = qw(Bio::Location::Simple Bio::Location::SubLocationI);
> 
> sub parent_seq_id {
> 	# implement get/set
> }
> 
> Similarly, one will probably like to have Location::FuzzySubLocation
> and Location::SplitSubLocation, for completeness. The definition of
> Location::SplitLocationI::sub_Location() is then changed such that
> returned objects can be expected to implement Location::SubLocationI.
> FTHelper constructs the XxxxSubLocation variant of objects for
> sub-locations of SplitLocations.
> 
> This would provide the functionality you want, provides for
> self-contained objects, and retains a clean object interface. At least
> IMHO.
> 
> A simpler solution would be to put parent_seq_id() into
> Bio::LocationI, which has the disadvantage of urging all location
> instances which are not sub-locations to provide a dummy value. 
> 
> What do you think? Jason, any comment?

Hmm nothing has jumped out at me as the obvious way to go here.  Just want
to be sure the added object complexity (adding potentially 3 classes and a
new interface ) is worth not having parent_seq_id return null when an
object is not a subLocation.  Do we recast/rebless Locations that become
sublocations or instantiate a new object each time?  We'd have to do some
$obj->isa gymnastics then.  I prefer the robust object model Hilmar is
proposing above I just don't want to go too overboard if we don't need to.

If you take a Tree data structure as an analogy to SplitLocations you
often have parent/child  pointers which are null but you don't
differentiate between parent and child nodes they are the same entity and
not subclassed.  So this is different since we want a reference of
something outside the tree so maybe I'm being simple minded again.

> 
> 	Hilmar
> -- 
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp@gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

Jason Stajich
jason@chg.mc.duke.edu
Center for Human Genetics
Duke University Medical Center 
http://www.chg.duke.edu/