[Genquire-dev] Feature::mod now redundant?

Mark Wilkinson mwilkinson@gene.pbi.nrc.ca
Fri, 04 Jan 2002 13:00:15 -0600


David Block wrote:

> The reason for Feature::mod was rw/ro *as well as* increment_left/right.
>
> That functionality should be moved somewhere else - but wait - it makes
> sense to leave it there!
>
> Convince me of a better place to put the size-changing code and I
> agree.  Otherwise, the added inheritance is not too painful and can stay.

Well... consider the following snippet of code in ShowSequenceContext:

if ($Feature->isa("GQ::Server::Feature::mod")) {    #i.e. it's a Feature from
the Feature table, but it's a hand_annotation
   $clone{'access'} = 'rw';  # must be made a read/write feature if it isn't
already
   $NewFeature = GQ::Server::Feature::mod->transform(%clone);         #This
turns $Feature into a Feature::mod
  } elsif ($Feature->isa("GQ::Server::Feature::Annotation")) {
   $clone{'access'} = 'rw';  # make it read/write
   $NewFeature = GQ::Server::Feature::mod->new(%clone);
  } else {
   $NewFeature = $Feature;    # if it is already a hand-annotation then just
hand it back to the calling routine
   $NewWidgetID = $WidgetID;
  }


most of the stuff above is completely redundant now.  If we moved the
"nudge-boundary" routines out of Feature::mod and into
Feature::GenericFeature, where the accessor checked that it was "rw" before
allowing the change, then all of this confusing code could be pulled out and
replaced with much cleaner (and up to date) code.

I don't think that keeping cruft around for posterity is necessarily a good
idea when we have found and implemented a fully comprehensive workaround
already...

M

--------------------------------
"Speed is subsittute fo accurancy."
________________________________

Dr. Mark Wilkinson
Bioinformatics Group
National Research Council of Canada
Plant Biotechnology Institute
110 Gymnasium Place
Saskatoon, SK
Canada