[Biococoa-dev] BCSequence class cluster

[Alexander Griekspoor]

>> 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.

I see, and that we certainly don't want, I agree.
>
> An alternative is to call the puclic class BCMutableSequence instead 
> now.
Actually, I like that idea very much, because the class simply is 
mutable and it allows a gap to be filled later.

> 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.
Perhaps this is the best way then, really nice in fact (except that it 
might again require many subclasses but I never found that a problem). 
And also maybe again to easily thought, but remember our "users" are 
developers who should do a lot of testing and debugging (ouch, that's a 
bate for a hot discussion), one golden rule is never to ship a product 
with compiler warnings (I know that Apple this is the case). My point 
of view (admittedly a simple one), if users start to ignore our 
warnings, then they are on their own.

> 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?)
YES!
> * 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)
YES
> * can we do it in the future with the class cluster design? --> same 
> answer, same ideas
YES
> * should we have something temporary already in place to ensure 
> backward-compatibility? --> my vote: yes; what do you guys think?
YES
> * if yes, how? --> I proposed 2 ways
I would go for the 2nd one, with a mutable subclass
>
>
>> 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.
> 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.
You're right, basically the mutable variant should always be a subclass 
of the immutable one and not the other way around. I think the 2nd 
option might work out the nicest.
Alex

*********************************************************
                       ** 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

*********************************************************