Once (#10) the target field is specified in a generalized way similarly to inits, the only field that will vary systematically between tasks will be inputs. In that case I suspect it will make more sense to eliminate subclassing of AbstractTaskTrialSpec, and instead define it as a generic final class, something like:
This would also save developers from explicitly including the intervene field in subclasses of AbstractTaskTrialSpec, because subclassing would be unnecessary; see #20.
I am still not sure how (if at all) to explicitly associate the structure of a given type of inputs, and the type of model that is compatible with a task. In principle, it could involve multiple fields of TaskTrialSpec; see #14.
Currently, typing in
feedbax.task
is a mess. A source of this mess isAbstractTaskTrialSpec
.https://github.com/mlprt/feedbax/blob/1c239e63e6ac029503050cc2cfa13c1d94e7e084/feedbax/task.py#L150-L167
Once (#10) the
target
field is specified in a generalized way similarly toinits
, the only field that will vary systematically between tasks will beinputs
. In that case I suspect it will make more sense to eliminate subclassing ofAbstractTaskTrialSpec
, and instead define it as a generic final class, something like:This would also save developers from explicitly including the
intervene
field in subclasses ofAbstractTaskTrialSpec
, because subclassing would be unnecessary; see #20.I am still not sure how (if at all) to explicitly associate the structure of a given type of
inputs
, and the type of model that is compatible with a task. In principle, it could involve multiple fields ofTaskTrialSpec
; see #14.