[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