I watched a video explaining that Grasshopper evolved from Rhino History. I assumed the data structure would be the same. As far as I understand everything inside GH happens around the Data Trees, but now it appears Data Trees are nothing but advanced lists. They do not contain information about how 2d/3d objects are changed they only contain lists of objects (being it 2d/3d, strings, int, float, transformations, etc)
If so, how is then History remembering “parent” objects. Is there a way via code/scripting to access “parent” objects from the history? Therefore, in a way to get the actual object not by defining it directly but through definition of its “parents”?
EDIT: After I wrote it down I realized that maybe you meant Rhino and not GH, so I’m leaving the comment anyway.
DataTree is a data collection, not a process collection.
You can find the parent components of another component by through the inputs, from each input to each source, and taking the proprietary object of the source (if it is not an isolated parameter, then it would be that same object).
There is no such history as in Rhino, GH is always in the present, somehow. The execution of the definition is only to update the state, that present. You can’t go back to the old state, you can “go back” with the old values, but it’s actually a new present with the past values.
GH_Document stores the objects, each object is executed when needed and in that computation process reads the input parameters. If this component is connected to a child component, it is also executed again. It do not need an execution hierarchy, as the components are reactive in this respect. On the other hand, the parameters store references to their sources or recipients.
To find an object you can search for it in several ways, either by directly analyzing the objects in the document (GH_Document_Instance.Objects) or by using some of its Find() methods.
Rhino’s command history and Grasshopper really don’t have anything on common.
Rhino command that support history simply record the inputs the the command - the stuff that makes the output.
When Rhino detects that the input(s) have changed, it runs the command again passing it the record of what was recorded prior. The command is then replayed, using the updated input(s).
Explicit History / Grasshopper started development before RhinoCommon, making use of RhinoCommon’s predecessor, Rhino.Net and was written at first mostly in Visual Basic.
So Explicit History / Grasshopper is a plugin that uses an API, while Rhino.NET and RhinoCommon are the APIs used to develop Explicit History / Grasshopper.
Now I understand that from the very beginning Grasshopper looked and behave pretty much like it is right now. It did not evolve out of Rhino “implicit” History. It have been more of a revolution.
I also understand that RhinoPython cannot access Rhino History. I cannot really modify an object by modifying its “parents”.
I guess what I need is a data tree that not only contains objects but also information how they are created. Information about their parents and the transformation they have undertaken. A mutable data tree of some sort. I’m gonna have to wait a bit for some future release where Rhino becomes database-based system, instead of a file-based one, and has the ability to store more dynamic parameters.