The following problem occurs quite often in pipelines: A PipeOp encapsulates some process (a filter to use for feature filtering, resampling and a learner to use for LearnerCV), which itself has some hyperparameters. Currently this is solved by taking the process as argument during construction (PipeOpFilter$initialize for example has an obligatory filter argument) which stays fixed for the lifetime of the PipeOp. The ParamSet of the PipeOp then consists of a ParamSetCollection with parameters of the PipeOp itself (number of features to filter) together with the parameters of the process (parameters of the feature filter method). It would be nice if the process (filter) could itself be a hyperparameter of the PipeOp. However, this would in the current state of paradox preclude the use fo the process's hyperparameters if the process is a hyperparameter itself.

Example, suppose the FilterJMIM filter had the threads parameter. Currently we can do

po = PipeOpFilter$new(mlr3featsel::FilterJMIM$new())
po$param_set$values$jmim.threads = 1

we could modify the PipeOpFilter to have a "filter" parameter that lets us change the filter of the pipeop. However, that would make changing filter parameters a bit tedious:

po = PipeOpFilter$new()
po$param_set$values$filter = mlr3featsel::FilterJMIM$new()
po$param_set$values$filter$param_set$values$thread = 1

It would be useful if these two things could be combined:

po = PipeOpFilter$new()
po$param_set$values$filter = mlr3featsel::FilterJMIM$new()
po$param_set$values$jmim.threads = 1

Then, if the user wants to tune over specific filter parameters (threads in this case) he can just tune with a ParamSet that contains the jmim.threads parameter. OTOH if he wants to tune over different filters he can use a ParamFct with a trafo that creates different filter objects depending on the filter to use.