<HTML>
<HEAD>
<TITLE>Re: [Biococoa-dev] more ramblings</TITLE>
</HEAD>
<BODY>
<BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
To a certain point yes, at least I agree with the latter part. I'm strongly in favor of the wrapper classes, I use them a lot myself and think they nicely separate the model from the "controller". Also, with convenience methods one can still keep things "hybrid" I think. <BR>
In principle, I don't believe in untyped sequences, but of course the biojava way shows one possibility to indeed have a general BCSequence that is typed by the attached BCSymbolSet (Alphabet) you attach to it. I'm not sure as I can't overlook many consequences and problems that this strategy has. Most important, I think that the current solution works nicely, though more methods could be transferred to wrapper classes. Finally, the annotation stuff and alike are indeed very general, but hey that's why they belong in the BCSequence super class right! <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
Yeah, the more I look at BioJava’s actual code, the less excited I become about using their progress as a model. Have you ever tried to trace through their process for translation? I never got to the point where I could see anything actually related to an amino acid. It calls through so many methods before it attempts to do anything that it must take about a half an hour to accomplish anything<BR>
<BR>
BioJava rant aside – I’m comfortable with the idea mentioned somewhere in Alex’s message of shifting the actual code for some of the sequence manipulation/calculation into wrapper classes, but providing call throughs to the methods in the sequence classes. Another alternative would be to have these methods attached as categories on BCSequences. With either of these, you would get Koen’s code separation and I’d be happy about the more direct connection of methods to data. <BR>
<BR>
<BR>
Anyway, to stir up more controversy around here, I had always envisioned something along the following structure:<BR>
<BR>
Sequence bundle<BR>
(groups related sequences)<BR>
|<BR>
Sequence wrapper<BR>
(holds features, notes, etc.)<BR>
|<BR>
Sequence<BR>
<BR>
<BR>
The reason being that I see features as being abstractions, not inherent to any type of sequence. They’re mostly a bit of information and a range it’s relevant to. There are some exceptions to this – for example, a phosphorylation site changes the MW of a protein – but they are largely exceptions. These exceptions are going to be difficult to handle regardless – how to tell if a site is or isn’t glycosylated is going to be very context dependent. The majority of features (ORFs, kinase domains, restriction sites, etc.) don’t require that sort of heavy lifting.<BR>
<BR>
Just something else to think about....<BR>
<BR>
Cheers,<BR>
<BR>
Jay<BR>
<BR>
_______________________________________________<BR>
This mind intentionally left blank<BR>
</SPAN></FONT>
</BODY>
</HTML>