2.2.2 – Table Mixin Columns – conceptual background?

[dhomeier]

Wondering if that section could use some brief introduction into the concept of a mixin.
At least at my level of English and (lack of) background in OO programming, this repeatedly pops up as some sort of enigmatic class everyone is using or talking about, but one has to do some research to find out what it actually represents.
If the paper is addressed at a general science audience and not mainly software developers (or scientists with more up-to-date CS training), it should perhaps include a short description of what defines a mixin, and what typical uses are.
Remotely related, the difference between table.Column and io.fits.Column may not be very meaningful to an average reader with limited insight in astropy internals – either this would be entirely unsurprising, being classes in quite different sub-modules that happen to share the same name, or one would need to go into more detail as to how they are indeed used in similar, but not identical contexts, and the latter is tied to a specific storage format, while the former is designed as part of a relatively general data container – seems to me one could discuss, at a similar level, the differences between (e.g.) table.Table and io.fits.BinTableHDU.

[adrn]

I think these are good ideas and things we could address! I don't think they will get in before submission, but maybe you or one of the authors of this section (@nstarman or @mhvk) would be interested in contributing some added context or updated text to address this?

[nstarman]

Sounds good. I can do it this weekend.

[dhomeier]

Cool. I don't feel quite qualified to write it myself, but happy to review!

[mhvk]

Similarly happy to have a look!

[nstarman]

I've pushed a PR (#126) to rephrase the relevant sections. Reading through the paper and comparing to official python docs (https://docs.python.org/dev/library/collections.abc.html) I think it would be best to remove the word "mixin" altogether. astropy.table "mixin" columns are not strictly "mixins" in the Python sense, more an interoperability protocol controlled by class composition (the "info" attribute). As an aside, maybe we should coin "compin" for the compositional equivalent to inheritance's "mixin".