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:
Define as non-Thing, most probably object
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.
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.