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