how to keep cross-cutting but optional model parts separate (e.g. social class)?

[mhinsch]

I would rather not have if pars.useClass peppered throughout the code...

[AtiyahElsheikh]

Example please for an alternative?

[mhinsch]

It's a genuine question, i.e. I don't have a perfect solution either. For social class what I did was to factor out the code that used social class into separate functions which can then be swapped out (relatively) easily if necessary.

[AtiyahElsheikh]

I am thinking if we delegate each parameter as a a function argument, there could be cases with functions requiring so many arguments. On the other hand, having parsas an argument is a way to unify (as much as possible) how low-level translated unit functions .. doX(people,pars,data,etc.)

[AtiyahElsheikh]

Not also ignoring potential code extendability / modifiability, we rather extends the fields of pars rather than function prototype.

[AtiyahElsheikh]

Just though about naive solution this morning, if I understood correctly struct fields to be converted into named tuples and making use of the operator...