On Friday, January 4, 2002, at 11:00 AM, Mark Wilkinson wrote: > 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. > This code is out of date and inaccurate, that's for sure. There is no GQ::Server::Feature::Annotation anymore, so the middle test is pointless. Why the %clone dereference? That is direct access to an object, not using methods to change attributes. Bad. The whole test is wrapped in a test for rw access, so changing access to rw is unnecessary. Most of this piece of code needs to be chucked in any case. I don't know what this has to do with Feature::mod. I may agree with you, but this code is not a good argument. > 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... > workaround==hack. What's the real solution? is rw access checking strong enough protection? I'll take another look. > 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 > > > > > _______________________________________________ > Genquire-dev maillist - Genquire-dev@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/genquire-dev > > -- David Block (858)812-1513 Bioinformatics http://www.gnf.org dblock@gnf.org Just ridin' the Coaster...