We currently assume that back ends generate code for expected_response, inv_link and sample_response functions. This assumption shows up in e.g. Fit#fitted where we directly call these methods as e.g. self.model.expected_response_fn. (Here self.model is something like a structure holding all of the assets produced by code gen.) This works, but one can imagine other approaches that a back-end could take to provide this functionality that don't require code generation. To that end, this change adds expected_response and friends to the Backend class, meaning that a back end still has to provide this functionality, but has freedom in how it does so. This PR doesn't change how this functionality is provided at present, so these new methods on Backend just delegate to the generated code.
I think this justifies making this change, but I also have a concrete use for this in mind. (It's a stepping stone to #11.) If you're unsure this is OK, perhaps we can merge and revisit after #11. Alternatively, I could combine this and the changes for #11 into a mega PR, though that might not make things much easier.
We currently assume that back ends generate code for
expected_response,inv_linkandsample_responsefunctions. This assumption shows up in e.g.Fit#fittedwhere we directly call these methods as e.g.self.model.expected_response_fn. (Hereself.modelis something like a structure holding all of the assets produced by code gen.) This works, but one can imagine other approaches that a back-end could take to provide this functionality that don't require code generation. To that end, this change addsexpected_responseand friends to theBackendclass, meaning that a back end still has to provide this functionality, but has freedom in how it does so. This PR doesn't change how this functionality is provided at present, so these new methods onBackendjust delegate to the generated code.I think this justifies making this change, but I also have a concrete use for this in mind. (It's a stepping stone to #11.) If you're unsure this is OK, perhaps we can merge and revisit after #11. Alternatively, I could combine this and the changes for #11 into a mega PR, though that might not make things much easier.