Implementing a form of Global Variables

So I have recently run into two instances where it would be really useful to allow a user to define some variables once, and then access those variables in lots of places.

For example:

A user would drop in a custom component called "DEFINE" and feed it some data, for simplicity, lets assume it has to be text data... Like the strings "foo", "bar", and "baz". The user also specifies that the pieces of data should be available under the name "assumptions 01".

There can be a maximum of one DEFINE component per script. The DEFINE component would check that it is the only DEFINE component in the script, and trigger an error if any others are found.

So then, elsewhere in the script, the user drops in a READ component. This component would allow a user to request the data stored as "assumptions 01" and return a list, "foo", "bar", "baz"

I think the right way to do this would be to have each READ component go looking for the DEFINE component, and then check its inputs and decide if the requested data exists there, return it, etc. The problem I foresee is that without wires connecting the components, changing inputs on DEFINE might not cause the READ nodes to recognize the changes and re-solve. This could probably be overcome though by triggering a manual re-solve..

I think this is preferable to having the DEFINE component try to create/ save anything for a whole host of reasons explored on lots of other threads.

I'm curious if anyone has tried to do something like this, or if there are aspects of this solution that are naive. Am I in for a world of hurt if I try to implement something like this via a custom visual studio plugin?

Thanks!

Replies to This Discussion

Permalink Reply by Michael Pryor on October 4, 2017 at 2:04pm

I've seen some stuff like that around. My question I guess is what would be so different than just plugging a global value into a data param, making the wire hidden, and copying this data param to wherever you need it.

Permalink Reply by Matthew Breau on October 4, 2017 at 2:25pm

My reasoning is something like this:

I want to enforce the "set once, use everywhere" paradigm

I want to simplify the process of retrieving a particular value from a list (ie named keys with values)

I may want to implement the ability to grab nested information, eg tower1.floorlevels.lvl4

I may use flux to give users the ability to set up more complex objects in Excel, and then import the objects into Grasshopper, "DEFINE" them, and then reference them

I hope this doesn't sound too pretentious, but a lot of the work I'm doing these days is looking at bringing object-oriented principles into GH's workflow and allowing users to treat their creations as objects, without them needing to actually understand what object orientation is.

Permalink Reply by Daniel González Abalde on October 4, 2017 at 2:21pm

I'm not sure I understood correctly. But just in case, there is a not recommendable way to use the same instance through components via wires (to recompute down streams). You can create your own GH_Param and avoid copying the data (make a false duplicate method), to keep the same instance. You would also need a wrapper for the data that receives this parameter to always be a reference type, since value types like strings or integers do not keep the same space in memory when them are assigned to different variables. I have no idea what possible problems can come out of this, but if what I have said makes sense to your problem, you can try.

Permalink Reply by Tom Svilans on October 5, 2017 at 1:07am

Anders is the king of this, but with Python you can use the sticky dictionary, which I believe lets you define dictionary entries that are persistent across all of Rhino, not just GH.

Example here:

https://gist.github.com/yasushisakai/143484ce4918de37e63b

Permalink Reply by Anders Holden Deleuran on October 5, 2017 at 3:36am

That's correct, sticky is a Python dictionary (i.e. a key/value mapping) that is accessible from all RhinoPython environments in one Rhino instance/session (i.e. the EditPythonScript editor and all GHPython components in all open Grasshopper documents). Hence, anything you add/remove/edit will occur across everything (which can be confusing and lead to unexpected behaviour if one is not aware). To create global variables that are exclusive to the current Grasshoppper document, you can gets its GUID and append this to the key values of the sticky when you set them. Attached an old example file.

Attachments: