[Dynamite] Is this working now then?

[Ian Holmes]

On Mon, 6 Mar 2000, Ewan Birney wrote:

> 
> > * a Sequence interface with virtual 'name' & 'data' attributes
> > * a Sequence_memo datastructure mirroring the Sequence interface
> > * a Database_sequence interface that inherits from Sequence and also has
> >   accession_number & implementation_id attributes (your Foreign_seq)
> >   -- possibly a get_subseq method as well (I like this.)
> > * a Database_sequence_factory
> > 
> 
> I think now you are mixing the database "identification" problem with
> the memo/non memo stuff. I would argue for:
> 
>    Sequence Interface with 'name','data'. Sequence interface has
>    get_subseq and momento datastructure
> 
>    Database_Sequence with 'accession' and 'primary_id'
> 

Yep, this makes more sense.

> 
> > This keeps the object model clean, decouples the DP from the database
> > layer. There is no uniqueness guarantee provided on the Sequence::name
> > method; uniqueness is a quality that is only relevant where there are
> > multiple sequences, i.e. the database layer.
> 
> I am fine with this. The very same change was forced on me in BioCorba:
> we went for names:
> 
> 	AnonymousSeq -> sequence with no names
> 	PrimarySeq   -> sequence with names (3 of them)
> 	Seq          -> sequence with names and features.
> 
> I will put money on the fact that even things declared as
> AnonymousSequences never get used as pure anonymous seq, but I am
> fine on this.


Actually I wouldn't bet against you -- I was trying to say that even an
AnonymousSeq should have a name. (This fits in nicely with the idea that
everything should have a debugging display method.) But the other two
names belong in the next level up (PrimarySeq in this case).


> 
> > 
> > Also, since Database_sequence is an extension of Sequence, we can put the
> > code to take a snapshot of a Sequence in the Sequence_memo constructor
> > (where it belongs) instead of creating a new object.
> 
> Again, I think you are missing the point of my previous idl definition
> a little but I am not going to bitch about this.

:-)

> 
> I think we have something (introducing another name here, "LightSeq").
> 
> module Seq {
> 	
> 	struct LightSeq_str {
> 		string name;
> 		string seq;
> 	};
> 
> 	interface LightSeq {
> 		attribute string name;
> 		attribute string seq;
> 		string get_subseq(in long start, in long end);
> 		LightSeq_str get_LightSeq_str();
> 	};
> 
> 	interface DatabaseSeq : LightSeq {
> 		attribute string primary_id; // implementation unique id
> 		attribute string accession_number; // biological unique id
> 	};
> 
> }
> 
> 
> Please - take it apart again.

No I think this is fine ;-)

...OK, a couple of minor naming gripes ;-)

Can we rename "LightSeq_str" --> "LightSeq_momento" in accordance with
Gamma et al

I thought before that get_LightSeq_str() was wrongly located in the
LightSeq interface -- it belongs in the constructor of LightSeq_str.
However, I now realise it's not that straightforward because data-only
structures have no methods & hence there is no equivalent of a
"constructor" method in IDL. Hmmmmmmmm.

Finally can we please rename "primary_id" --> "implementation_id" because
I find "primary ID" confusing.

> Also I do think we should try to use IDL when possible otherwise it
> doesn't clear in my own head what you mean...

OK but to some extent you will have to keep prodding me for it -- we've
tossed around a lot of ideas this morning, & I wouldn't have been able to
write half as much if we hadn't been able to throw around design patterns
jargon. (Of course you might think it'd be better if I hadn't written half
as much...)

Here is my suggested revision of the sequence IDL


module Seq {
        
        struct LightSeq_momento {
                string name;
                string seq;
        };

        interface LightSeq {
                attribute string name;
                attribute string seq;
                string get_subseq(in long start, in long end);
                LightSeq_momento make_LightSeq_momento();
        };

        interface DatabaseSeq : LightSeq {
                attribute string implementation_id; // implementation unique id
                attribute string accession_number;  // biological unique id
        };

}