Closed aklawonn closed 3 years ago
First of all, thank you for taking the time to check out my modifications so quickly! So, let me explain. The main idea of protecting the attributes is that (in general) you cannot change one of them without having to change something else as well if you don't want to mess up your problem. For example, you cannot just change a latent parameter's role to 'const', without taking care of the prior and the prior's parameters that were attached to this latent parameter. I don't see this as an underlying issue. Of course we could let the user do what she wants, also if it messes up the problem, but for me this approach is not attractive if this tool should not only appeal to a handful of experts. However, I agree that in this case, the info and tex attribute don't need to be protected. I changed that in the last commit.
One more comment: you write that you find it inconsistent that "Read access to the parameter attributes is (only) possible via the attributes, write access is handled indirectly via the inference problem". For me, this is not inconsistent, but exactly the goal of this issue. The write access is handled by the inference problem (or are permitted entirely), because it also takes care of all cleanup-tasks that might be necessary, when you want to change one of the protected parameter properties. Read access however, is unrestricted, because there is no harm in reading these properties.
As discussed on the phone, I will merge this branch as it is now, and @TTitscher will create a new issue regarding a decoupling ("ent-wurbeling") of dependencies in the problem's parameter structure.
… directly anymore. This fixes #10