[Biococoa-dev] Sequence Structure
charles.parnot at gmail.com
Mon Jul 11 17:01:08 EDT 2005
I thought a color version of the chat might be easier to follow
charles = purple
ok, let's get started on the NSMUtableData?
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
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
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
the question was whether you could override: '-(NSData *)data
with '-(NSMutableData *)data
I'm not sure
no you can't
then we have a problem
you get a compiler warning
you have to do '-(id)data'
if you look at the NSArray/NSMuutableArray headers,...
you have '+(id)array'
this is because you cant' have +(NSArray *)array
i get the idea
We should have '-(NSData *)data' for both mut/immut and...
add the method '-(NSMUtableData *)mutableData' to the mutable one
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
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!!!
this was my point!!! Yeah, you got it??
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
the immutable class don't need to copy it, because it won't change
only the mutable class should copy it
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?
let me answer your question
no, we don't need an extra ivar.
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.
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
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
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
just like I did with BCSequence and my recent email
you are saying they are using that lazy copy trick
lazy copy trick??
ah, ok, yes, they are!
they only make a real copy when it is a mutable instance
it is probably not lazy, though
so the implementation of '-copy' is
they do a real copy if flag = mutable
otherwise just copy the pointer
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
remember, the user wants direct access to the data
serge seemed to say that this is not that expensive
which can be 300Mb
well, then he should use immutable sequences perhaps
but then the user should use the BCSequence methods
yes, 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
the concept of mutable/immutabnle is more subtle that it seems at first
this should be documented this discussion
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?
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
i don't like omni graffle anymore
and complicated the first time does not mean you have to alwasy
rememeber how it works
if you never have to change it
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
i'm willing to give up direct typing
interesting turn of events!!
the wwdc has certainly created some storm
well I'm really enthusiastic about the nsdata
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
not necessaarily. I actually propose the oppsite, just as suggested
yes, exactly totally agree, the other way is better,
as it could live a separate life
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
just something more hidden, less needed
This is a better omnigraffle
only one arrow
and almost straight arrow
but I just didn't feel like thinking too much about it
first, John would like to go for it I guess
the concept is there. The implementation can be wrapper of placeholder
and second, it's an add-on/plugin so could wait
wrapper OR placeholder
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
Well, let's do it
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
i'm enthusiastic about the discussions, although heated
yeah, i know about 'time';
That would be the consequence of the approach
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
yes, we had a discussiona bout that a few months ago
and more complex things like translations, digestions, alignments in
that still holds
although a basic translation method could be there as convenience method
should we copy paste this whole chat to the mailing list?
i'm not sure
it's quite arbitrary
fine with me
it is arbitrary, yes
I need to get back to work
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 for the copy, don't make it lazy
speak to you later
More information about the Biococoa-dev