On Thu, Apr 04, 2002 at 11:52:53AM +0100, Matthew Pocock wrote:
> Hum,
>
> I would be happy if equals and hashCode on feature worked by being
> equivalent to delegating to the return value of makeTemplate - this includes
> all info except the children and parent. Since features can access both
> children and parents, you would potentialy get into a circular stack if you
> took hashcodes or equals of all fields.
That's actually the current situation. There are sensible
equals and hashCode methods on Feature.Template (which actually
work by reflection -- sub-classes of Feature.Template don't
need to implement anything). SimpleFeature has equals and hashCode
methods which just wrap the corresponding methods on the Template.
[This has been the status quo for a few months, now -- I implemented
it over christmas, when I found that I needed sensible .equals
behaviour to get the BioCorba bridge working correctly. Before
that, features were only equal by object identity].
I've just noticed that the equals behaviour isn't documented
on the Feature interface (although it is on Feature.Template).
Unless we decide to change things, some suitable doc comments
should definitely be added...
> Are there cases where two "equivalent" feature instances wouldn't produce
> the same templates? Are there any cases where two "non-equivalent" features
> would produce the same template (baring parent/child issues)?
I don't think so -- the template and the Feature should match
pretty closely.
One interesting case would be `exon' features which are shared
between two (or more) `transcript' features. Under the
"equal Template" criteria, these are all equal, even though
they have different parents. To me, that sounds like the right
behaviour -- can anyone think of a case where things would break?
Thomas.
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
