We're using a d.r. object for value function for instance

[sbenthall]

#188 (comment)

[albop]

In my opinion, this is not really a bug, since we consistently call "decision rule" a function f(m,s) where m is a vector of exogenous states, and s a vector of endogenous states. Also note that there is a little bit of flexibility in the naming: what we call control is not necessarily the control of a controlled stochastic process (it can also be a price in an equlibrium model with two agents), and you could perfectly treat a value as a regular control to be solved using time iterations...
Now, I'm sympathetic with the idea of using another name to denote function f(m,s) , but I'm not clear about what that name would be. Function is not specific enough (and we use it for all kind of purposes like the accepted functions in a yaml file: sin, cos, etc.). One could think of concepts like fields, surfaces varieties, but they would all be more confusing.
On the other hand, I don't see any reason to not define a special value function object with to be returned by VFI algorithms and other. Easiest way to do would be class ValueFunction(DecisionRule): pass until a better parent object is defined.
Beyond naming, a potential advantage, of using a different kind of object could be to optionally exploit some known math property of the value function, like concavity, and use, for instance, shape-preserving splines.