[Biococoa-dev] BCSequence implementation

Alexander Griekspoor mek at mekentosj.com
Wed Feb 23 05:41:02 EST 2005


Hi phil,

We previously had this discussion as well so I guess it's a relevant 
one. In principle I don't have a problem with categories (anymore ;-) 
to add these features and keep the base class lean and small. I would 
strongly argue to keep them in the same .h/.m file though (like apple 
seems to do). The real question then of course is, how do I get a 
slimmed down sequence objects without the added categories? Is that 
possible at all? And perhaps the real real question is, does that 
really matter? Does your code becomes slower when you add methods and 
arguments but don't use them? I can hardly imagine that a pointer to a 
dictionary (even kept nil if you don't add annotations) make a lot of 
difference in the end. With symbols I can imagine, but with sequences?
Perhaps we can discuss this in analogy to NSString. That seems a class 
very alike to our sequence class and it does contain many methods. Can 
you describe how you see the design of NSString and the similarities 
with our class? How would you implement the categories?
If I take a quick look at the NSString header file, I see

@interface NSString : NSObject <NSCopying, NSMutableCopying, NSCoding>
[..] //base
@end

@interface NSString (NSStringExtensionMethods)
[..] //most methods
@end

@interface NSMutableString : NSString
[..] //mutable base
@end

@interface NSMutableString (NSMutableStringExtensionMethods)
[..] //most mutable methods
@end

@interface NSString (NSExtendedStringPropertyListParsing)
[..] //some plist stuff
@end

So yes, they use categories as well, with a very simple NSString base, 
and the rest implemented as extensions.
BUT, unless you ask for a NSMutableString, you get ALL methods if you 
ask for an NSString right?! So how would you get the base string only? 
That can only be if this would be the public header, while internally 
they have kept things separated (multiple headers), so that they 
internally can use the base classes, and we not). OR we decide to keep 
all extensions separated with separate headers that you have to import 
to add the functionality to the sequence class. I'm not sure though 
whether it would than be wiser to make subclasses instead of spreading 
the code of the sequence class throughout different files.... hmmm... 
Again the question is if there's a real advantage of having a very 
minimalistic basic sequence class...
Anyone wants to jump in?
Alex





On 23-feb-05, at 10:08, Philipp Seibel wrote:

> Morning everyone,
>
> i think we should be careful by adding more and more features to the 
> BCSequence. We have to keep in mind that for many sequence related 
> algorithms it is better to have a sleek Object. We shouldn't design a 
> full featured object as base class. I think categories is the best 
> solution to add features like Annotations and Features to the Sequence 
> object.
>
> cheers
>
> Phil
>
> _______________________________________________
> 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: 4159 bytes
Desc: not available
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050223/5555f3aa/attachment.bin>


More information about the Biococoa-dev mailing list