[Biococoa-dev] Base test

[John Timmer]

This is the first of two messages, since I think we need to split things
into separate topics.

> Why do you have a separate class for each base? Idon;t think that's how
> a singleton is supposed to work (although I don't have an example ready
> now that shows you how it *should* work :-).  You could just have a
> BCSequenceUnit (or whatever we decide to call it) class and create a
> base by eg passing only a name.  All the info about each base can be
> stored in an external plist file. The same BCSequenceUnit class can be
> used to create other structural objects.  This way most code for
> getting name, properties is written only once, instead repeated for
> each type of sequence unit.

Okay, the singleton aspect comes from the fact that every reference to
Adenine anywhere in the program points to the same object.  I'm sure there's
other ways to define singletons (some of which may be more technically
correct), but I think this is a reasonably valid one.

Just a general technical note on the sequenceunit idea if we decide to go
that way - we'd have to split nucleotides and everything else somewhere in
the inheritance chain, since they have the concept of a complement that
pretty much everything else lacks.

I'm intrigued by the idea of a template .plist file, since it would
definitely save a ton of work.  The problem I see with it is that its really
difficult to store a reference to another base.  I think it would require
all lookups of other bases to be done by symbol, since you can't store a
selector name as a string and then call a class method with it.  That means
that every time we need to complement a base, find the atomic base
representations, etc., we have to run through a switch/case with about 20
possibilities, in many cases doing so several times:

+ (id) baseForSymbol: (unichar)symbol {
    switch ( symbol ) {
        case 'A' : {
            return [BCSequenceDNABase adenine];
            break;
        }
            
        case 'T' : {
            return [BCSequenceDNABase thymidine];
            break;
        }
            
        case 'C' : {
            return [BCSequenceDNABase cytidine];
            break;
        }
            
        case 'G' : {
            return [BCSequenceDNABase guanidine];
            break;
        }
            
        case 'N' : {
            return [BCSequenceDNABase anyBase];
            break;
        }
        
    // still have to add ambiguous bases, gaps, and a non-base holder

        default :
            return nil;
    }
}


I think it's a question of work up front vs. efficiency in use, but I could
have missed some way of implementing this which gets around a lookup table.

On the plus side, it's pointed out a serious deficiency in something I was
thinking of doing.  During base initialization, I was going to create the
arrays of complements and representations.  This means every time the first
base was created, it would necessarily create its complement, all relevant
ambiguous bases, etc.  What I neglected to consider is that those would, in
turn, try to get a reference to the original base, which would still be in
the process of initialization.  Ugly.

I think I'll be moving array creation into the method that needs the array
the first time it's called...

> Finally, you don't need to implement the "superheader file" as a class, you
> can simply write an empty header file containing the links to the others
> leaving the rest empty (so you don't need the warning not to use the class).
> This would be enough:
Yeah, I was just having some trouble with Xcode not seeing the superheader
file at all, so I figured I was doing something wrong, rather than Xcode
misbehaving.  Re-creating the header/.m file combination fixed it, and I
didn't want to risk changing things again while it was working.

JT

_______________________________________________
This mind intentionally left blank