You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, creating ModelObject handler classes involves a syntax where a container object is passed in as an argument to the class _init() method when instantiating a new object. Then, container is stored as a reference from the object itself, and since the container contains a reference to the state Dict, the new child has access to this as well. The rationale, or utility, of the existing approach is that:
It allows the object to obtain it's state_path variable from it's parent, without knowledge of the parent path, since it has access to it's parent during the _init() process.
It provides access to the state variable for registration processes, which can allow for duplication checks, and location of linkages.
The child can register additional variables on the parent, as it has easy access to the parent object and methods (this can be disallowed by the parent if needed).
It then uses this state reference to store the object that is being created into the state['model_object_cache'] without needing extra variable arguments.
It reflects a real-world situation whereby the sub-entity chooses it's location, as opposed to being dependent upon the parent. In an agent based world, this may be the most common case, as opposed to the paradigm of children being "added" to parent (see below).
However, this can make for awkward looking syntax, and creates an un-necessary recursive relationship between state and container. This could be improved by:
Create an overall container object to hold distinct simulations and state records.
Container objects have method, add_child(), to handle creation/addition of child objects. (i.e. model_container.add_child(ModelVariable('child_var_name', 15.999))
Change class property container to a method container() that uses state_path or traces inputs to find the parent object, insuring no recursive references.
It may still be useful to pass in the container as a reference to __init(), but just to access things like the path, but do not store the container as a reference?
The class property state remains as a reference, but becomes a required input at object creation.
ModelObject class "inputs" still maintain references between child and parent (from the parent's point of view, the child only can know of the parent via the state_path)
Currently, creating
ModelObject
handler classes involves a syntax where acontainer
object is passed in as an argument to the class_init()
method when instantiating a new object. Then, container is stored as a reference from the object itself, and since the container contains a reference to thestate
Dict, the new child has access to this as well. The rationale, or utility, of the existing approach is that:state_path
variable from it's parent, without knowledge of the parent path, since it has access to it's parent during the_init()
process.state
variable for registration processes, which can allow for duplication checks, and location of linkages.state
reference to store the object that is being created into thestate['model_object_cache']
without needing extra variable arguments.However, this can make for awkward looking syntax, and creates an un-necessary recursive relationship between
state
andcontainer
. This could be improved by:add_child()
, to handle creation/addition of child objects. (i.e.model_container.add_child(ModelVariable('child_var_name', 15.999))
container
to a methodcontainer()
that usesstate_path
or tracesinputs
to find the parent object, insuring no recursive references.container
as a reference to__init()
, but just to access things like the path, but do not store the container as a reference?state
remains as a reference, but becomes a required input at object creation.state_path
)@austinorr
Object Interface Changes
def __init__(self, name, container = False, model_props = None, state = None)
The text was updated successfully, but these errors were encountered: