Hi folks,
We have datamodel classes for Alignment and Sequence which may (respectively)
contain an (Alignment or Sequence) dataset.
I've had long-standing confusion in understanding when an object is or isn't
(or has or hasn't) a dataset.
A couple of suggestions that might help with this.
1) I'd like to propose adding a flag / method in each class / interface
boolean isDataset
so we can identify explicitly when the object is a dataset.
This would be safer than the method currently used in some places
"if dataset is null then this doesn't have a dataset, so it must be a
dataset"
The problem is that that doesn't distinguish between a dataset, and a 'parent'
that hasn't yet created a dataset.
This is giving a lot of confusion in trying to maintain invariants like:
- sequence features, dbrefs and pdbids should be on the sequence dataset, not
the sequence
- mappings (AlignedCodonFrame) should be on the alignment dataset (currently
some are, some aren't!)
- copy constructors should preserve invariants (whether invoked for a dataset
or its parent) (a bit broken for Sequence)
2) enforce invariants in the classes (encapsulated); for example
Sequence.addSequenceFeature(sf) {
if (dataset != null) {
dataset.addSequenceFeature(sf);
} // and similarly for getSequenceFeature()
This is currently done this way for getSequenceFeatures() and getDbRef()
(differently) but not getPDBEntry(), and not for adders/setters.
In other words, make it the responsibility of the data model classes, not their
clients, to use the dataset where available.
This would simplify a lot of calling code that currently checks for existence
of a dataset.
3) abolish
Alignment.setDataset(null)
and replace it with (a new interface method)
AlignmentI.createDataset()
This would not change behaviour, but would be consistent with Sequence, make
the code intention clear, and make calls to this traceable.
4) check for (and reject) circular references in Alignment.setDataset(),
Sequence.setDataset()
That would mean that recursive calls (like at 2 above) are safe from infinite
loops and we don't need to check for this in these methods.
Mungo
Mungo Carstairs
Jalview Computational Scientist
The Barton Group
Division of Computational Biology
School of Life Sciences
University of Dundee, Dundee, Scotland, UK.
www.jalview.org<http://www.jalview.org/>
www.compbio.dundee.ac.uk<http://www.compbio.dundee.ac.uk/>
The University of Dundee is a registered Scottish Charity, No: SC015096
_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
