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

Mark Wilkinson mwilkinson@gene.pbi.nrc.ca
Mon, 07 Jan 2002 08:57:35 -0600


David Block wrote:

> Why the %clone dereference?  That is direct access to an
> object, not using methods to change attributes.  Bad.

:-)  not *my* idea, my son... I just do what I am told  :-)

You indicated that it was not possible to make a clone of a feature object by
passing the original feature as an argument, so I should derefernece it and
let the resulting hash args initialize the new object, effectively making a
generic clone of it.  It has worked so far... messy though it is.


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

yup.  I know that much... I just want to "chuck" it in the right direction,
and that seems to me to include ridding ourselves of an object which is no
longer particularly useful - that is Feature::mod.  Since *all* features are
now modifiable if they have 'rw' access, everything should either inherit
from Feature::mod, or we should take the useful bits of Feature::mod and put
them into GenericFeature (which is already in the inheritance tree).


> workaround==hack.  What's the real solution?  is rw access checking
> strong enough protection?  I'll take another look.

I believe it is strong enough... and if not, it is still the best direction
to go, rather than having a specific modifiable object.

Merry Uk'ian Christmas everyone!!

Mark


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

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