[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