Hi Uwe, Le 19/04/2018 à 18:42, Uwe L. Korn a écrit : >> 1) are we ok with paying the cost of pimpls? (mostly the indirection >> cost I guess, and the fact that we can't have inline methods/accessors >> anymore) > > I'm not sure about how much of the cost we're ready to pay. There is a > certain element to keeping a stable ABI (this is done fantastically by the > NumPy people), you can do patch releases without consumers worrying if they > need to rebuild their binaries. > > The indirection on paths that call expensive functions is certainly no > problem, i.e. if you have a table and select a column, this is an operation > you don't do often, thus I think the overhead is acceptable. On the other > hand, accessing the null_count or the length of an array is definitely an > operation that is performed quite often. These should be as fast as possible. > > I cannot give you a certain answer, once I have the relevant time, I'll try > to implement and profile some of the possible approaches. > >> 2) how do we do for things like ArrayData, which seems publicly exposed >> by design? > > ArrayData is marked as internal and thus I would feel ok to break its ABI > between non-major releases. If people really depend on its usage, then we > should think of a clear way to make it public / non-internal.
Perhaps we need a three-tiered approach? 1) a public and stable namespace ("arrow") with the goal to reach ABI stability post-1.0; 2) a public but still moving namespace ("arrow::unstable"?) where we generally try not to remove existing functionality and to honor API compatibility, but do not guarantee any sort of ABI stability; (this could have ArrayData, PrimitiveArray...) 3) an internal-use namespace ("arrow::internal"), which third-party projects can use at their own risk. (this should get all our internal helpers, including almost all CPython helpers) Regards Antoine.