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