Sanity Check on Mix-In Classes

With IFCOMP in the rearview (barring a few games still in the chamber), am back at work on the WIP! Decided some functionality was best implemented as a mix-in class. As usual, I went about it backwards: first digesting mix-in class definitions in the source code, then reading the docs. From there, I inferred two, and only two, rules to mixin classes:

  1. Define as non-Thing, most probably object
  2. List first or at least before Thing-based Class during instantiation (to ensure override precedence) eg. newObj : CustomMixIn, Thing

As far as I can tell, that is it! Any hidden gotchas to mix-in classes you folks have tripped over? I am only lightly tested, but so far that seems to get it done.


That looks right to me.

Nitpicky detail that you probably already know, but I’ll mention it in case others come along later with similar questions:

TADS doesn’t really have mixin classes, like those in Ruby or Rust. TADS supports full multiple inheritance, meaning all classes are classes, no qualifiers.

But, yeah, when you add a class that inherits from object to a Thing, it does look a lot like a mixin. It’s less true when you start mixing Thing-based classes together, like

class LockableContainer: Lockable, Openable, Container

where the parent classes all inherit from Thing.

(I’ll leave it there. The page in the TADS docs I linked to above goes deep on some of the thornier issues and problems with multiple inheritance.)


Yeah, I think it’s one of those things where the problems are all either: there’s just a couple simple rules to keep track of, and they cover everything you need to worry about; or the answer to your problem is a graduate thesis on language design.