[Biococoa-dev] BCSequence class cluster

[Charles PARNOT]

>>You will  notice that NSNumber does not have an mutable version. 
>>Why? One reason is that creating a new instance is not too costly, 
>>the data is small. Another reason is maybe that the implementation 
>>is a bit more tricky as the NSNumber resembles our BCSequence, with 
>>a large number of potential subclasses, and then the question of 
>>how to implement mutability and immutability.
>You're right, but in our case we're not talking about small 
>subclasses with only one variable (int, float, bool etc), the 
>BCSequences are way to big to return a new instance every time you 
>call a method on it.

That is also my point further down in the previous email. For 
NSNumber, Apple can get away by saying 'you don't need a mutable 
version, the immutable does not cost much'. But the user of BioCocoa 
would probably not be very happy with only an immutable version (and 
we would not be easier)... If we have to stick to just one version, 
we have to stick to the mutable.



>Therefore, I would propose to start with the mutable version, then 
>later we can always generate the immutable versions in addition for 
>optimization purposes.

OK, I agree with that. It seems easier to implement the mutable 
version first. The only problem is that the addition of the immutable 
class could break existing programs in the future. More specifically, 
if a program keeps using BCSequence as mutable objects and then 
suddenly the framework decides they are now immutable and the user 
should now use BCMutableSequence, there will be  a lot of rewrite 
necessary.

An alternative is to call the puclic class BCMutableSequence instead 
now. And not have a BCSequence class (at least no public class). So 
future introduction of BCSequence will not break old code. I know 
there is not so many applications relying on BioCocoa yet, but even 
if there are just one or two (like the examples in the CVS project), 
it might still be worth thinking about it now.

Another alternative is to have both public headers for in fact the 
same implementation. The implementation would be very easy:
* superclass BCSequence: header without the mutable-specific methods
* subclass BCMutableSequence: header with the mutable-specific methods
* the rest of the subclasses =  below that
Then, at least, the user gets some compiler warnings even if the 
mutable-specific methods actually will run fine on the immutable 
instances. Of course, there could still be cases not detected by the 
compiler and and that should be illegal at runtime (like if the user 
ignores the compiler warnings!!) and would still cause programs to 
break in the future. But that would be less frequent thanks to the 
compiler warnings.

Whichever way we implement it in the future, we have to make sure 
that it is feasible. It looks like we already have several options 
and opinions, so that's a good sign! We can decide how to do it 
later. So the roadmap is:
* do we want mutable and immutable objects? --> well, yeah, sure! 
(who would say no?)
* can we do it in the future? --> apparently yes, we have several 
ideas (it does not mean it will be easy to maintain code, we have to 
make the best decision at some point, and Koen raised that important 
issue)
* can we do it in the future with the class cluster design? --> same 
answer, same ideas
* should we have something temporary already in place to ensure 
backward-compatibility? --> my vote: yes; what do you guys think?
* if yes, how? --> I proposed 2 ways


>About the warnings, I'm not that much of a fan to add flags like 
>isMutable or isTyped, in the first case I would rather have a real 
>immutable subclass and in the second can't we just generate the 
>runtime errors, in general those will surface in 99% of the cases in 
>the development cycle and the developer can take countermeasures to 
>prevent the end-user from doing stupid things.
>
>Just my 2 cents,
>Alex

The problem with an immutable suclass is that it would inherit the 
methods in the mutable superclass, and thus the user would not get 
compiler warnings when using a mutable-specific method on a immutable 
class.

About the isTyped, see my response to Koen (I am planning of talking 
about it there too). It seems we all agree that the user can deal 
with just one class, BCSequence, and live with it. Providing 
additional headers for stronger typing was just a future possible 
addition and I was suggesting some ways it could be done, 
anticipating some needs, and seeing if these could be fulfilled in a 
class cluster design. But my feeling (and it seems, yours too) is 
that such a need will probably never come and should not be 
fulfilled. It will tend to duplicate code.

Charles


-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021


-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021