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

[David Block]

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...