SINTEF / Splipy

Spline modelling made easy.
GNU General Public License v3.0
100 stars 18 forks source link

Clarify type stability issues #174

Open TheBB opened 4 months ago

TheBB commented 4 months ago

I have been working on automatic type checking in Splipy. This is quite challenging, because Splipy has been written to be extremely lenient in terms of types, and many functions return one of several different types based on input parameters. For example, SplineObject.split is a particularly egregious offender: it returns either a list of objects or (if the original object is periodic) only a single object. Since there's no way to encode whether an object is periodic or not in the type system, it's impossible for a type checker to know whether .split returns a list of objects or a single object in any particular case (even though the programmer does!).

I propose to phase out those functions and replace them with more stable alternatives. We can potentially leave behind the incriminating function to prevent destroying existing code, but I don't want to use them in Splipy if at all possible.

In this issue I will list out each relevant case as I find them.