Multiple inheritance vs. Dynamic inheritance vs. Conversions

Codes are, like many mathematical objects often members of multiple classes at the same time. Sometimes this can be known at construction time, e.g. a narrow-sense Reed-Solomon code is always cyclic, but at other times one should investigate the construction to know.

Python suppors multiple inheritance at design time, so e.g. NarrowSenseReedSolomon could inherit from CyclicCode and overwrite certain critical things, such as computing a generator polynomial at construction time.

That approach fails if we instead want only one GeneralisedReedSolomon class, or - more generally - we are considering a code class A for which a difficult-to-describe subset are also elements of class B. In that case, one could provide a method is_member_of_B, but the question is then in the affirmative, how to access the methods of the class B for the object X of A.

I (jsrn) see two possibilties:

• Conversion functions: Provide a function on class A, get_B_object_if_member, which returns the corresponding B object, if X is indeed a member of B. This has the disadvantage that now what is mathematically one object is represented as two X_A and X_B. For instance, improving bounds on dimension for X_B is not easily transferred to know the same things about X_A. It is not inconceivable that this information could in A lead to new information on, say, the minimum distance, but that this is hard to obtain since X_A and X_B are programmatically distinct.

  On the other hand, it is relavitely clean. It also allows for the X_A and X_B to provide their respective natural representations of, say, generator matrices (e.g. ReedSolomon uses Vandermonde, while cyclic uses cyclic shifts of the generator).

• Dynamic inheritance: Python allows dynamically modifying objects after creation, even to the extend of adding entirely new parent classes. Thus, one could automatically on an affirmative call to is_member_of_B patch X to now also inherit from B, and thereafter providing the methods of B on X.

  This yields finally only one object X which is both A and B. Apart from being a slightly distasteful solution to type purists, there is a clear maintenance problem: if B is modified to have additional private fields, all functions patching some X to dynamically inheriting from B requires update.

  We also do not have the option of presenting generator matrices naturally from either A or B but arbitrarily have to choose which one we want.

I (Daniel) understand the above dicussion as a developper/maintenance discussion. From a user point of view, wouldn't it be practical to add fonctionnalities to a code, during an interactive session, to explore and compute with the code ? We could be inspired by a "hook" system to attach such things. One exemple : suppose that user manipulates a code C and finds it equivalent to a Reed-Solomom RS, using for instance a Sidelnikov-Chestakov like algorithm. The morphism between the two codes could be "attached" to C, for further manipulations.