[Biococoa-dev] RE: Nomenclature

Alexander Griekspoor mek at mekentosj.com
Fri Aug 13 13:41:29 EDT 2004


Part 2:

> Okay, the BCSequenceDNA was just a first stab at thinking of the 
> methods we’d want.  Once I filled them in, I’d think about which ones 
> would work generally across all sequences, and move them to the 
> superclass, which I haven’t defined yet.  What you saw was the 
> twistings of my mind in action ;)

I know how that goes when you're coding.... ;-) Don't take a look at 
some of my methods, often I have a lot of renaming to do for the sake 
of being a bit more logical...

> That said, mentally I was reserving BCSequence as the wrapper for a 
> type of sequence and all the additions – features, format conversion, 
> etc.  I was thinking more along the lines of:
>
>                         BCSequenceGeneric
>                          |
>  BCSequence      |
>  Contains an       |
>  Instance of ->   ----------------BCSequenceDNA
>                          |
>                          |
>                          ----------------BCSequenceProtein
>
>
>
> That said, it would violate the naming conventions I’d argued for, so 
> I hereby reject my own thinking.  Given that, what do we call the 
> wrapper object on the left then?

I was thinking of the following two options, but perhaps someone comes 
up with something must better.

BCRecord - Based on a record from a nucleotide database like entrez. 
(BCEntry would be another variant). Advantage: familiar setup 
(sequence, name, features, etc). Disadvantage: sometimes it's a bit 
strange to call things a record, like if you're cloning for instance, 
your not messing around with BCRecords. But perhaps in this case you 
are busy with BCFragments, derived from a BCRecords so it's not that 
bad after all.

BCEntity - My favorite. BCUnit is to boring, but a more general, 
"building block of our framework" name would perhaps be apporiate here. 
Anyway, you might be laughing at it right now...


>  I think this all makes life a bit simpler to implement John. I like 
> the addition of the proposed equality testing methods you mention:
>  - (BOOL) complementsNucleotide: (BCNucleotide *)entry; (would be 
> BCNucleotide specific)
>  - (BOOL) representsSymbol: (BCSymbol *) entry; (do you mean here to 
> test whether this base belongs to an ambiguous group?)
>  And would like to add:
>  - (BOOL) isEqualToSymbol: (BCSymbol *) entry;
>
>
> Wouldn’t NSObject’s “isEqual” method work just as well here?
I guess you are right because we use singleton objects.

>
>  And the second method (which I wrote this morning) looks like:
> - (BOOL) representsBase: (BCSequenceDNABase *) entry {
>      if ( [[self matches] containsObject: entry] )
>          return YES;
>      return NO;    
>  }
Really elegant!

> It works if you have an ambiguous base as self, and get handed another 
> base.
In fact that works with every base, also the atomic ones as their 
-(NSArray *)matches; method should return only one entry: self.

Almost there.....
A.


*********************************************************
                      ** Alexander Griekspoor **
*********************************************************
                The Netherlands Cancer Institute
                Department of Tumorbiology (H4)
          Plesmanlaan 121, 1066 CX, Amsterdam
                   Tel:  + 31 20 - 512 2023
                   Fax:  + 31 20 - 512 2029
                  AIM: mekentosj at mac.com
                   E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

    The requirements said: Windows 2000 or better.
    So I got a Macintosh.

*********************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4949 bytes
Desc: not available
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20040813/d6f0e31a/attachment.bin>


More information about the Biococoa-dev mailing list