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
ModelObjecthandler classes involves a syntax where acontainerobject 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 thestateDict, the new child has access to this as well. The rationale, or utility, of the existing approach is that:state_pathvariable from it's parent, without knowledge of the parent path, since it has access to it's parent during the_init()process.statevariable for registration processes, which can allow for duplication checks, and location of linkages.statereference 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
stateandcontainer. 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))containerto a methodcontainer()that usesstate_pathor tracesinputsto find the parent object, insuring no recursive references.containeras a reference to__init(), but just to access things like the path, but do not store the container as a reference?stateremains 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)