[Biococoa-dev] Sequence Structure
Alexander Griekspoor
mek at mekentosj.com
Mon Jul 11 16:04:48 EDT 2005
Hi everbody,
Charles and I just had a little chat about the mutable vs immutable
discussion we have had on the list. Perhaps it's nice to copy it here
for everyone to read.
Cheers,
Alex
AIM IM with Charles Parnot <cparnot1>.
21:10
[snip]
-ok, let's get started on the NSMUtableData?
-yes
-lots of discussion and kind of stuck right
-So what I mean is: you return an NSMutableData, the compiler
sees an NSData, so you can't modify it.. This is good, but...
-yes, that's what I had in mind
-but the BCSequence might modify the object later
-how?
-that was my point
-the immutable subclass should alter the data
-none of its methods should
-sorry should not
-The mutable class can modify the ivar, right?
-can modify the content of the ivar, I should say
-yes, the mutable class
-but the mutable class should also return a mutable data object
so the muutable class returns the poiinter to that ivar, right
-yes
-OK, what if the mutable class returns an NSData (from the header)
the immutable class as well, only casted to NSData
can't we override the method to be typed as mutabledata?
-Is there a '-(NSData *)data' method in the mutable class header?
-that was the only question I had
21:15
-the question was whether you could override: '-(NSData *)data
with '-(NSMutableData *)data
-I'm not sure
-no you can't
-never tried
-I tried
-then we have a problem
-you get a compiler warning
-you have to do '-(id)data'
-yep
-if you look at the NSArray/NSMuutableArray headers,...
-you have '+(id)array'
-aha
-this is because you cant' have +(NSArray *)array
-and +(NSMutableArray)array
-i get the idea
-We should have '-(NSData *)data' for both mut/immut and...
-add the method '-(NSMUtableData *)mutableData' to the mutable one
-or not
-hmm, yes and no
-in any case, the object returned by '-data' should be immutable
and not just cast to immutable
-in fact, now that I think of it
-yes?
-oh no, john doesn't like the idea of return an nsdata that in
reality is an nsmutabledata right
-I still don't see the problem
-as we don't allow editing of the mutable array directly,
you ONLY need to publish the NSData
if your mutable class returns a pointer to its mutable ivar...
and tyhe user thinks it gets an immutable data...
because remember that ALL editing should go through methods
we shouldn't allow editing of the array directly!!
then the user might keep that object around thinking it won't change
that would make syncing impossible
when it fact it will change as the sequence is edited
-The user WILL NOT edit the NSData but will see it changed!!!
-true
-this was my point!!! Yeah, you got it??
-yep
-so now how to solve it
-basically we need the same approach as NSArray NSMutableArray
-There is only one way to solve it: return a true NSData by
copying it...
-how did they solve it then?
-that would make it slow
-and especially the immutable class is added for performance reasons!
-there is another solution
-wait...wait...
-the immutable class don't need to copy it, because it won't
change
-true
-only the mutable class should copy it
-yes,
-but what you are saying is to have the mutableversion have an extra
(private) ivar to store the data
to improve performance, like I said in the email, you could still
retrurn the NSMutableData...
sorry I was following on previous stuff
-leaving the other one unused?
-no, we don't need an extra ivar.
-pfew
-We just have to be careful inside the class implementation the
ivar can be a NSMutableData for the compiler, but we would in fact
use NSData for the
immutable of course, if we call a mutability method on it, we
get a runtime exception, but it should never happen if we a re A BIT
careful
-i get it
-now, back to above.
- yes
-to improve performance in mutable sequence, like I said in
the email, you could still retrurn the NSMutableData...
-but also have a flag to say: next time we return the data
or mutate the seq...
-we can't use the current object pointed by the ivar.
Somebody else is using it as NSData
-so the flag say: netx time, copy it
-if next time never happens, no copy!
-hmm, that doesn't sound to nice I think, although functional
-performance trick are often anti-good code
-true
-now, back to the question i had earlier
-this is a 'lazy' copy
-ok, back to it
-how did apple solve the mutable vs immutable code?
-in which case?
-well, they have NSArray in mutable and immutable form
-they use a flag internally. I found that on the cocoadev
mailinglist
-and NSMutableArray seems to be a subclass of NSArray
-these are just header tricks
-aha
-placeholder classes
-just like I did with BCSequence and my recent email
-you are saying they are using that lazy copy trick
-wowowwowowo
-lazy copy trick??
-haha
-sorry
-ah, ok, yes, they are!
-sort of
-they only make a real copy when it is a mutable instance
-it is probably not lazy, though
-not sure
-so the implementation of '-copy' is
-they do a real copy if flag = mutable
-otherwise just copy the pointer
-aha
-that makes sense
-and i don't think they defer the real copy in the -copy method
-but the situation is different
-the user asks for a copy
-it should expect to be done immediately
-performance can't be great
-yes, you are right
-if you ask a copy, you know what you are doing
-the thing is that I'm afraid copying is out of the question anyway
-don't know...
-remember, the user wants direct access to the data
-serge seemed to say that this is not that expensive
-which can be 300Mb
-well, yeah
-well, then he should use immutable sequences perhaps
-but then the user should use the BCSequence methods
-y es, use immutable if you don't want to edit
-but then the user should use the BCSequence methods to edit
-well, in the end it's inevitable
-you don't want the data to change underneath
-yes! Inevitable is the word
-this should be documented this discussion the concept of mutable/
immutabnle is more subtle that it seems at first it is
-but coming back to a discussion
-we could copy and paste the whole chat?
-ok, back to the discussion
-imagine this to mixed with a discussion about 4 types of sub(sub)
classes
-mutable vs immutable is already difficult enough
-well, you read my email?
-i truly believe that symbolsets is our typing
-it was a bit complicated, no? yes
-too much\
-and remember last time we choose such an approach
-yes, I know...
-i almost had to phone you to ask how it worked complicated for the
developer does not mean complicated for the user necessarily
-i don't like omni graffle anymore true
-and complicated the first time does not mean you have to
alwasy rememeber how it works
-if you never have to change it
-all fine
-anyway, at least you got one of my concern
-but the one-sequence-for-all is so much simpler (in interface terms)
that I think that will pay off big time
-probably, yes
-i'm willing to give up direct typing
-interesting turn of events!!
-yes!
-the wwdc has certainly created some storm well I'm really
enthusiastic about the nsdata
-as storage
-it's cool!
-hafing typed sequences more for the 'expert' user could be fine
too
-see my last email
-no other biox project has it, but I like the idea
-yes, if you could wrap it certainly!
-i kind of dropped of there
-typed sequence would be like the CFArray
-for more advanced user!
-but that would imply the typed once being the basis and the untyped
one the wrapper
-and I don't like that too much
-the otherway around is fine with me
-as it could live a separate life
-not necessaarily. I actually propose the oppsite, just as
suggested byu John
-yes, exactly totally agree, the other way is better,
-read the email looke at the omnigraffle thingie
-I thought to remember that from your email, i did read it
-OK, in the grpah, it is really separate, like a plug-in on
the side
-I didn't get the CFarray analogy therefore
-bad analogy
-haha
-just something more hidden, less needed
-This is a better omnigraffle
-less friendly
-only one arrow That's good!
-and almost straight arrow
-but I just didn't feel like thinking too much about it
-the concept is there. The implementation can be wrapper of
placeholder
- it's an add-on/plugin so could wait wrapper OR placeholder
-oups
-yes could wait or be there and don't care
-perfect, the only thing I would like to see is that it doesn't
require tricks in the "clean" one-for-all bcsequence system
-it does not
-perfect!
-Well, let's do it haha
-you agree the BCSequence header has ALL the methods?
-if I have just as much time as you, then we have an even bigger problem
- although I would like to spend a few days if I had time
-including -complement
-i'm enthusiastic about the discussions, although heated That would
be the consequence of the approach
-yeah, i know about 'time';
-all methods
-ok for the methods
-I think we should define a limited number of basis methods
-let's see what john thinks
-the rest will have to be tools
-that's the way it is
-but think in terms of strider
-yes, the tools/method line
-I was thinking of all basic editing simple transformations to be in
bcsequence
-yes, we had a discussiona bout that a few months ago
-and more complex things like translations, digestions, alignments in
tools
-that still holds
-yes, perfect
-although a basic translation method could be there as convenience
method
-i'm not sure
-it's quite arbitrary
-it is arbitrary, yes
21:45
-I need to get back to work ok
-nice talking to you again, and thanks for making your point clear
-I get it now
-thanks for listening!!
-Have a nice day at work
-I'll copy the discussion to the list
-thanks!
-thanks for the copy, don't make it lazy
*********************************************************
** 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
*********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050711/a41bda9b/attachment.html>
More information about the Biococoa-dev
mailing list