[Biococoa-dev] Base test

[Alexander Griekspoor]

I agree, this setup would indeed save a lot of work and keep things 
simpler. The plist with data is a great idea as well, in fact not much 
changes as you can still call [BCSequenceUnit adenosine] as a class 
method with would invoke BCSequence init and get all the rest filled in 
from the plist (which is easily extendible as well). If the requested 
symbol name is not found in the plist, an exception is raised or error 
generated and no instance returned. If we don't use this setup adding 
or updating a single method in the 60 classes we would get, quickly 
would become a nightmare.

Could we agree on the following names? If anyone prefers another one, 
let it know, but it would be nice if we can decide what to take (saves 
a lot of typing ;-)

BCSymbol (instead of BCSequenceUnit)
|
|
------------ BCNucleotide (instead of BCBase)
|
|
------------ BCAminoAcid
|
|
------------ etc (think BCSaccharide and alikes)

I think BCFunctionalGroup should be a feature (like phosphates) and not 
a symbol, but perhaps I am wrong here.

For sequences I would propose to take the names Koen already mentioned:

BCSequence
|
|
----------------BCSequenceDNA
|
|
----------------BCSequenceProtein


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;

To implement "savability" we would just have to implement the NSCoding 
protocol, that allows you to save arrays/dictionaries to contain these 
objects. Although it would perhaps be nice if there was a method to 
output these to some kind of plist like format in addition.

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:

*******************************
//
//  BCSequenceDNABases.h
//  BioCocoa
//
//  Created by John Timmer on 8/12/04.
//  Copyright 2004 John Timmer. All rights reserved.
//

#import "BCSequenceDNABase.h"
#import "BCSequenceDNAAdenine.h"
#import "BCSequenceDNAThymidine.h"
#import "BCSequenceDNACytidine.h"
#import "BCSequenceDNAGuanidine.h"
#import "BCSequenceDNAAnyBase.h"

*******************************

What do you think John, would the setup proposed by Koen be easy to 
implement? I'm curious what you think.
Cheers,
Alex



Op 13-aug-04 om 0:50 heeft Koen van der Drift het volgende geschreven:

> John,
>
> 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.
>
>
> So for instance:
>
> BCSequenceUnit
> |
> |
> ----------------BCBase
> |
> |
> ----------------BCAminoAcid
> |
> |
> ----------------BCFunctionalGroup
> |
> |
> ----------etc
>
>
> I also suggest that BCSequenceDNA should be a subclass of BCSequence, 
> just as BCBase /BCSequenceDNABase should be a subclass of 
> BCSequenceUnit:
>
> BCSequence
> |
> |
> ----------------BCSequenceDNA
> |
> |
> ----------------BCSequenceProtein
>
>
> - Koen.
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
                     ** 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
                   E-mail: a.griekspoor at nki.nl
	        AIM: mekentosj at mac.com
               Web: http://www.mekentosj.com

                  EnzymeX - To cut or not to cut
              http://www.mekentosj.com/enzymex

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