[Biococoa-dev] New Structure for BioCocoa

[Peter Schols]

I fully agree with Alex. It seems most logical to me if IO would be  
part of BCFoundation.

peter


On 04 Jul 2005, at 10:50, Alexander Griekspoor wrote:

> About the IO discussion.
> If we want a separate IO framework(s), I would suggest to keep all  
> IO in one framework, the examples you give are all sequence  
> related, so would depend only on the core framework (BCFoundation)  
> right. If say the HMM framework would need some kind of special  
> structure, than we can always opt to either define the structure in  
> the foundation, but put all other stuff in the HMM framework, or  
> place the HMM specific IO in the HMM framework as it is probably  
> consists of only a few  methods anyway.
> But my main question is whether we really want to separate the IO  
> framework as being independent. BCFoundation is so much related  
> with IO that I don't really see a need to separate them. Most  
> important, I don't think the IO will be so much code that it will  
> be a large framework, or that it will make the foundation so  
> bloated. It's two files right now! So why don't we make  
> BCFoundation contain the IO like it does now. And the HMM framework  
> contains its IO etc.
> IMHO a basic core that defines sequences and can IO them doesn't  
> have to be separated in two, I see it as one core. Similar to the  
> fact that NSString can also IO them without the need of an IO  
> framework.
> Cheers,
> Alex
>
>
>
> On 4-jul-2005, at 1:20, Koen van der Drift wrote:
>
>>
>> On Jul 3, 2005, at 3:12 PM, Philipp Seibel wrote:
>>
>>
>>> Sorry, but i got lost :-). I just meant that we can't put all io  
>>> of all Frameworks in one IOFramework, because this IOFramework  
>>> will then depend on all Frameworks ( Foundation ,HMM,  
>>> Phylogenetics, etc.) because it will use the structure classes of  
>>> all of them. To solve this problem, we will need a seperate  
>>> IOFramework for each of the Frameworks.
>>>
>>>
>>
>> Aha, but now I understand :) I didn't realize that you were  
>> assuming different data structures for each data format.  Maybe we  
>> should put some effort in creating a general internal data format  
>> that will also allow easy  exchange between the various formats.
>>
>> cheers,
>>
>> - 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
>                    AIM: mekentosj at mac.com
>                     E-mail: a.griekspoor at nki.nl
>                 Web: http://www.mekentosj.com
>
>           LabAssistant - Get your life organized!
>           http://www.mekentosj.com/labassistant
>
> *********************************************************
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>