Pattern 3
This a bit more advanced, but if you’re already delving into contraptions, it isn’t too bad to figure out.
The final way that I’ll store and manage data is to add an “internal” widget to a contraption and then expose setting and getting the widget’s data via a contraption attribute, whether it’s a field, grid, checkbox, etc. I’ll usually “hide” the widget that was added to the contraption off of its visible space.
The main benefit to storing “state” (our values, variables, data, etc.) in a contraption is (1) if we have some complex logic that is part of the a contraption itself manipluating the data (2) we also want access to that data “outside” of the contraption in another card and (3) we expect to have multiple instances of those contraptions and data.
For an example, if we have a “player contraption” that stores its health and we expect to have multiple players and there’s a bit of programming we added to make the player look injured: while we could store each individual player’s health on the outside in a global variable, hp_player1, hp_player2, hp_player3…
What if instead we have a contraption called player, with multiple copies of it named: player1, player2, player3. Then, the player contraption has a field that stores the player health in a widget named hp. And, we also allow access to their hp from the outside, per player, like player1.hp, player2.hp, player3.hp, etc.?
So, what we might say is here is this a “separation of concerns” or “encapsulation” or “modularity.” The data are “inside” each of the contraptions, where there might be lot of programming related to updating the appearance of a player (a canvas image showing that the character is injured, which is part of the contraption). But, we might also need the player’s health on the “outside,” too, for when we need to update a player’s health because they got hurt, player1.hp: player1.hp - monster1.harm
Here’s an example of a field inside of a contraption and having access to the field’s data from the outside. Assuming we have an internal field named “field1” inside of a contraption “prototype1”, we put this in the prototype’s (menu Prototype->Script…) script:
on get_myvalue do
field1.text
end
on set_myvalue x do
field1.text: x
end
Then under the menu Prototype->Attributes, we add a new property named “myvalue” with type “text” (assuming we’re using the field for simple text storage via .text). The attribute name must match the “set_” and “get_” methods on the contraption script, i.e., “get_myvalue” and “set_myvalue”.
When we instantiate a contraption of “prototype1” named “prototype11” we’ll be able to do this:
prototype11.myvalue: "hello world!"
show[prototype11.myvalue] # console shows "hello world!"
and then add another one:
prototype12.myvalue: "not the same"
show[prototype12.myvalue] # console shows "not the same"
Where both contraptions have their own value of myvalue as it appears from the outside, but inside the contraption it is called field1.text. Their field1.text are separate “instances”. While they appear to be the same variable, they are not. They’re separate copies. Kind of like how prototype11 and prototype12 are similar (they inherit the same scripts), they each have their own data that the scripts operate on, making it different.
Here’s some screenshots showing this:
there’s a missing screenshot that should go here that shows opening the Prototype->Attribute menu and adding a new attribute called myvalue
