[Biococoa-dev] (no subject)

[Koen van der Drift]

On Jan 6, 2005, at 1:35 AM, Charles PARNOT wrote:

> Yes, I understand that. I discussed it in the initial super long email 
> (part 7, I believe?!? Even I have some trouble remembering it all...). 
> The reason why I picked BCSequence for the superclass name is because 
> this would become the only public class, and I thought the name 
> BCSequence would be a  better public name than BCSymbolList.

Yes, I think that would be the best approach. Can we make BCSymbolList 
a super of the class cluster (just as NSValue is the super of 
NSNumber)?


> The problem of course is that it is different from the current 
> implementation, which had also good reason to use these names. So I am 
> actually proposing the names:
>
> old name                   new name
> --------                  ---------
>                 BCSequence (no instance variable, only public header)
> BSSymbolList           BCSymbolList
> BCSequence              BCSeq
> BCSequenceDNA   BCSeqDNA
>
> with an inheritance tree parallel to the existing one. An alternative 
> is to not have an 'empty' class at the top and go with the following:
>
> old name                   new name
> --------                  ---------
> BSSymbolList           BCSequence
> BCSequence              BCSeq
> BCSequenceDNA   BCSeqDNA

What about using _BCSequence instead of BCSeq? Whith the underscore we 
know exactly what tyoe of class we're dealing with, BCSeq <-> 
BCSequence seems more confusing to me.

>
> We have to talk more about the role of BCSymbolList in the context of 
> a class cluster, though. When creating an instance of a subclass of 
> the class cluster, when should we choose BCSymbolList? In the case 
> when there is no annotation? In this case, we have to make sure that 
> BCSymbolList will respond to all the messages. Once an instance is 
> created, we cannot decide to suddenly make it one of the typed 
> subclass just to be able to handle a message not implemented by 
> BCSymbolList.
>
> We could also decide to have BCSymbolList and BCSequence both publics 
> in the existing code. There might be some good reson for that... 
> speaking of which ... in fact, I have a question on how the current 
> implementation is supposed to work. It would be up to the user to 
> decide wether to use BCSymbolList or BCSequence? And this choice would 
> be made depending on what the user wants to later do with that 
> object/sequence? I know I already asked some questions about it, but 
> could you develop a bit more the reasons and the usage. Thanks:-)

Not sure yet how the user should approache this :). In general there 
should be one class that is always used throughout. Now I think of it, 
BCSequence is really the best choice for it. Annotations are a nice 
extension, but not always needed.  Maybe we should dump BCSymbolList at 
all, and only use BCSequence. It can have an empty annotation ivar, 
which is not very costly. One of the reasons to introduce the 
BCSymbolList was to avoid the introduction of even more subclasses 
classes with long, clumsy names such as BCAnnotatedDNASequence.

> Sorry for being so 'dogmatic' in the previous email. It is now clear 
> we have a very similar view of the whole thing! We all want to have a 
> minimal number of methods in the subclasses. In a few cases, optimized 
> versions may still be possible with this design.

Sounds good, just as long as this is hidden for the user, in other 
words, in theose special cases, the user should still only use 
BCSequence, not the specialized subclass.

>
> BTW, the reason that BioJava uses immutable sequences is: " It is 
> worth noting that many BioJava implementations of Sequence and 
> SymbolList do not allow edit operations as this may invalidate 
> underlying Features or Annotations." That's indeed something to keep 
> in the back of our minds. Clearly, managing annotations on a mutable 
> sequence is a problem. Which also occurs when you cut a piece of a 
> sequence and return a new instance. I can clearly see that a separate 
> class would be in charge of the job. This would be the job of one the 
> BCTool, right?

I suppose so, I haven't looked into that yet.


>
>
> So, now the 1 million dollars question: you did not tell yet what you 
> think of the whole class cluster design and if you like the idea...;-)
> (I have to say the more I discuss it, the more I like it, just for the 
> simplicity and the level of abstraction it would give to the users of 
> the framework...)
>

I don't know yet. One thing I didn't like that came of the discussion 
is the possibility for the user to use strong typing. If we can make 
the class cluster in such a way that the user only sees BCSequence, 
then I am all for it. In that case I could even be persuaded to have 
both mutable an immutable versions of each subclass.


cheers,

- Koen.