[Biococoa-dev] BCSequence class cluster was:(no subject)

[Charles PARNOT]

>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.

That indeed may be a better naming scheme, though I have never seen that applied anywhere (a bit unorthodox?). It seems that ivar starting with undescore are supposedly reserved for Apple now, but these would be class names, not ivars, so technically, we would not breaking the rules!


>>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)?

Yes, we can certainly do that, and it seems it would be the only way to keep BCSymbol around. It may not be used very much... actually just as NSValue is not used very much. The purpose of NSValue is mostly to allow further subclassing in future implementations (this is just a guess, Apple is not very clear on that). I don't know if there would be such uses, but it is worth the discussion.

I also agree with the discussion below and we may end up dumping BCSymbolList anyway! (as least as a concrete subclass)


(about the purpose of BCSymbolList)
>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.

OK, so it seems the main purpose was to provide a light-weight version for non-annotated sequence. It seems at some point, when adding annotations, the team decided to subclass BCSequence into BCAnnotatedSequence. The renaming then was a way to avoid long class names  (that I remember now from reading the archives) .

I totally agree that an ivar for annotation is not going to use much memory if nil (4 bytes) or empty (4 bytes + sizeof(ivars of NSArray)), particularly when you already have an NSArray for the sequenceArray that should contain in 99% cases at least 10 items (peptides), and most of the time many more (think plasmids!). So "light-weight" class is actually probably wrong.

However, I could see the case for code separation, the superclass without annotation taking care of the non-annotation methods, and then the annotated subclass taking care of the annotation-related methods. In this case, the current BCSymbolList could be an abstract class and remain hidden in the class cluster as a private subclass, at the top of the class hierarchy, just below the pulic class (or it could BE the public class; this goes back to my previous emails with the different propositions for class hierarchies). We end up with one public class being able to do everything, and all the concrete private subclasses capable of handling annotations.

If the purpose is to separate the code for annotations, an alternative is to use a category, and not a subclass. And I think I like that better, actually.

My feeling after all these discussions about annotations is that we should be able to make annotations a general and abstract concept that encompass all the different types of sequences, which means most of the code could go in the superclass. Just like you already did with BCSymbol being able to take most of the details away from BCSequence.... OK, I already said all of that before in previous emails, I know;-)


>>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 those special cases, the user should still only use BCSequence, not the specialized subclass.

Then we agree totally! :-)



>>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.

I don't like strong typing either. As I said before, Alex does not seem to like it either. It also seems you don't and it may have driven your argument against subclasses, you seem to prefer general methods that do something (including run-time errors?) on all types of sequences, even if not always relevant. The class cluster design is then a good fit.

Peter still thinks there is a case in favor of stronger typing to restrict the irrelevant tasks as much as possible. I will discuss it in a separate email. This one is long enough!

Charles

-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021