[Biococoa-dev] Misc

[Alexander Griekspoor]

> At 1:37 PM +0100 1/8/05, Alexander Griekspoor wrote:
>> Yes, I agree, if we can get rid of BCSymbollist and only have one 
>> class (BCSequence) that would have my preference too. Just my 
>> stupidity, adding many methods to a class (which we need to keep 
>> annotations in sync and add/remove them etc) doesn't make it more 
>> costly to use  memory/speed wise?
> At 1:37 PM +0100 1/8/05, Alexander Griekspoor wrote:
>> Exactly my point, I'm not sure though, the first (and foremost) 
>> question is whether putting everything in one class doesn't matter 
>> memory/speed wise (I'm not talking about the small unused ivars). 
>> Second, how much will the sequence class increase code-wise to a 
>> point where things become unpractical. For example, I have 
>> experienced opensource projects where classes have become so extended 
>> that you can't say extract one class for use in a custom project 
>> without spending hours unwinding everything unnecessary, where with a 
>> class you basically have to incorporate the whole project to make it 
>> work. Maybe not so much of importance, but usually the more simple 
>> the code and easier to overview, the more useful and versatile it 
>> turns out to be.
> I am not sure about performance issue. But they should not be an issue.
> About subclass versus large class, my wild guess is more subclasses 
> will have the runtime lookup the class hierarchy more, while more 
> methods will have the runtime lookup the method list more (this is 
> some pure science, here). With the caching and all, well, euh...
Sometime ago we had a discussion about this as well, and the caching 
indeed resolves this issue to nil what I've read..

> About code bloating, yes this could be a issue on the developer-side.
>>
> What is the problem with categories?
> I think I may understand what you mean: categories on an Apple object 
> like NSDictionary are not welcome? No, they are not. But indeed, we 
> are talking about private classes, so we do what we want (and Apple 
> does it a lot, look at the headers of NString or NSArray, for 
> example). You just have to put all the @interface in the same header 
> file.
Yep, that was what I meant, we shouldn't do public categories on our 
own classes, but internally they are actually very nice, if you look at 
the apple headers they're often all in the same header, but somehow 
they nicely separate different parts of the code (almost like #pragma 
mark). And as the bcsequence class grows it might be nice to do

@interface BCSequence : NSObject
....
very general methods
....
@end

@interface BCSequence (annotations)
...
annotations methods
...
@end

@interface BCSequence (tools)
...
convenience methods
...
@end

etc

> At 2:20 PM +0100 1/8/05, Alexander Griekspoor wrote:
>> Hey, we can have the same approach we're now taking for bcsequence 
>> (are we? ;-) for such tools as well can't we? Have a public tool with 
>> private subclasses depending on the fed sequence subclass...
> I did not dare to bring that up... Let's just keep it for ourselves 
> for now.
ha ha ;-)

> --------
>
> Sorry guys, your reading is not done. I  am planning on sending 
> another email with some further ideas following John, Peter and Alex's 
> concerns with not having strongly typed classes. I hope what you will 
> read will please you...
Can't wait!
Alex

**************************************************************
                         ** 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

MacOS X: The power of UNIX with the simplicity of the Mac

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