[interfacekit] Re: How backwards compatible?

My only suggestion with regard to this is to not code in such as way as 
to *preclude* adding R3 compatibility later, if need be.

e

>I am working on BPropertyInfo and I have run into a minor issue.  I 
>have a plan to address it, but I want to check with some people on the 
>mailing list first.
>
>Prior to R4, the struct property_info structure had only five elements 
>to it.  With R4, the structure was changed and three new elements were 
>added to it.  This means that code that pass a property_info to a 
>BPropertyInfo class using the old header from R3 will have a different 
>size structure than what is found in R4.
>
>To handle this, Be changed the constructor for BPropertyInfo.  The old 
>R3 constructor was moved so it became private.  However, existing 
>binaries will still use this private constructor and this constructor 
>knows the structure passed in is the old format and it converts it to 
>the new structure.  Any code compiled on R4 or newer will use a new 
>constructor.  Because it is compiled on R4 or later, the right 
>property_info structure and BPropertyInfo constructor gets called.
>
>So, the question becomes should I bother to implement the code to 
>convert between the old property_info structure and the new one (as of 
>R4) and implement this private constructor.  Here are the things I have 

>considered:
>
>- On Intel, R4 was incompatible with R3.  So, all current Intel BeOS 
>binaries should not be using the old constructor/old structure format.  

>I have checked all ELF files on my BeOS machine and confirmed that none 

>of them link against this deprecated constructor.  From this 
>perspective it should be safe not to implement it.
>
>- On PPC, R4 is compatible with R3.  If OpenBeOS is to be compatible 
>with PPC in the future, we will need this constructor etc in order to 
>run PPC binaries from R3.  Personally, I think this isn't too likely.  
>If we do end up with a PPC version of OpenBeOS, I suspect it will not 
>be compatible at all and be based on the gcc toolchain.
>
>- I am worried that there may be flattened R3 BPropertyInfo's out there 

>on someones harddisk, even on Intel.  Perhaps Be handled unflattening 
>these also.  If we don't implement support for old BPropertyInfo 
>unflattening, we may have some minor compatibility issues.  I think the 

>risk here is very low however.
>
>Given all of this, I have decided _not_ to implement this backward 
>compatibility to the R3 BPropertyInfo interface.  If anyone has any 
>concerns about this, please let me know.  Thanks.
>
>--
>Jeremy Rand
>jrand@xxxxxxxx

Necessity is the plea for every infringement of human freedom. It is the 
argument of tyrants; it is the creed of slaves.
        -William Pitt, British prime-minister (1759-1806)

Other related posts: