Replacing the use of Mixins with composition
🚀 Feature
Use composition instead of inheritance and mixins.
A typical way of using this would go something like the following:
In such a world, the trainer can be instantiated like so:
trainer_instance = Trainer(dataset_reader_instance, model_instance, training_loop_manager, callback_instances_list, platform_specific_kwargs ...)


Here, everything non-essential including logging, early-stopping, etc. goes into the callbacks. Every callback while registering itself with the trainer, will tell the trainer what attributes it requires on the trainer to function. Once all the callbacks register themselves the trainer does a sanity check — warn if multiple callbacks want to access the same attribute, error out if two callbacks have asked for exclusive write access for an attribute, etc.
Additional benefit:
Now, the issue would be that the user has to instantiate these different instances in their final training script. We can automate that using a config manager like in AllenNLP and provide the user with a standard CLI train, test, predict commands. This way if a user wants to use their own dataset to train a model, they need to define a reader class for it in a separate file, modify one line in an existing config JSON or YAML file and use CLI command train new_config.yaml
Concern:
If the worry is that the user needs to learn about all the callbacks to even start training a model, then that can be addressed by providing a sample/default config file which includes the configuration for all important callbacks. So in essence, if the user wants to use the default training setup, they just need to copy the default training config file and change the model and dataset configuration.
Motivation
Code using mixins is hard to read, debug, extend and test if the mixins are not completely decoupled. Moreover, using composition coupled with an automatic way of instantiating classes will make for a very clean and fast user interface.
Pitch
Currently, the same as what is provided above in the Feature Proposal. Will update as/if things become more concrete.
Alternatives
Decouple the mixins, define their responsibilities clearly and have detailed "for developer" documentation describing these.
Additional context
Slack conversation link