[Biococoa-dev] Base test
Peter Schols
peter.schols at bio.kuleuven.ac.be
Fri Aug 13 03:57:49 EDT 2004
Hi Alex,
Oops, it seems like I've misinterpreted the meaning of a singleton
(although I've used it a few times myself in my own apps). I'm just now
reading through the backlog of list messages as we are currently
rebuilding our house and moving everything to it. Anyway, thanks for
the link, this removes my only concern ;-)
peter
On 13 Aug 2004, at 09:45, Alexander Griekspoor wrote:
> Peter,
>
> Just to recapitulate, the BCSymbol classes are singleton objects,
> meaning that they are instantiated only once no matter how many time
> you ask for one. Everytime you call for a BCSymbol you get the same
> instance back. At the end the only thing you are storing is a single
> pointer instead of an object. This is the same way Cocoa's
> sharedDefaultManager works and pretty much every object that has
> "shared" as a prefix. The other bio frameworks have tackled the
> problem using the same approach. Check out this link:
> http://www.biojava.org/tutorials/chap1.html (scroll to "Doesn't this
> waste all memory?" for an explanation.
>
> Alex
>
> Op 13-aug-04 om 9:20 heeft Peter Schols het volgende geschreven:
>
>> Hi Koen and others,
>>
>> This seems like a very good architecture to me.
>> The naming scheme makes sense as well, so maybe - as Alexander is
>> suggesting - we should try to agree on this one.
>> My only concern at this point is that a new object will be created
>> for every base. This might lead to performance problems with huge
>> datasets (e.g. entire genomes). On the other hand, the other Bio
>> frameworks seem to use a similar implementation so if it works in
>> Java, it should definitely work in Cocoa ;-)
>>
>> peter
>>
>> On 13 Aug 2004, at 00:50, Koen van der Drift wrote:
>>
>>> 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
>>
>> _______________________________________________
>> 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
>
> Mac vs Windows
> 65 million years ago, there were more
> dinosaurs than humans.
> Where are the dinosaurs now?
>
> *********************************************************
>
More information about the Biococoa-dev
mailing list