My reference to "accessors" was for something simpler, though I suppose you could also use custom props for such things, and many do.
To separate my data store from the code that uses it, I usually have functions and commands to get and set data in the store, as opposed to, say, working on global variables directly.
So rather than write:
Code: Select all
global gMyData
get line 2 of gMyData -- where line 2 is the user's name
...
I just write:
...and elsewhere in my message path (usually a library) I'll have the definition for that accessor:
Code: Select all
function UserName
global gMyData
return line 2 of gMyData
end UserName
The overhead of calling the function does mean it takes more time to execute, but that time difference is a fraction of a microsecond so in most cases it's well worth the expense in performance for what it does to help keep code more manageable.
If I need data obtained from an accessor in a repeat loop, I'll often get it once before entering the loop and use a local copy to keep that performance impairment from adding up:
Code: Select all
put UserName() into tUser
repeat 100
DoSomethingWith tUser
end repeat
You could also use properties, and for many cases they're very handy, esp. when the data you're accessing relates to a specific object such as a custom control like the DataGrid. GetProp and SetProp handlers that can be very useful for invoking behavior in addition to obtaining and storing data.
But I tend to use custom properties sparingly, usually only for data bound to a specific object, for a few reasons.
First, being a lazy person (meaning "the less I type the faster I ship") this:
...is simply easier to type than:
Code: Select all
get the uUserName of button "SomeObject" of stack "SomeStack"
Extra bonus points that I don't need to remember which object my data is stored in.
Even when the data is ultimately stored in a property, accessing it with a function or command frees me from needing to remember the object's descriptor, and usually means less typing.
Moreoever, using accessor handlers gives me the opportunity to change my storage entirely if I want down the road. For example, today I may be using custom props in a stack file as my data store (my favorite file format, so easy to work with), but later on I find that I need to migrate to using a database like SQLite. By using accessors I only need to change a handful of accessor handlers in one library script, and all of the code throughout the rest of my code base that uses them won't need to change at all, it'll just work.
Also, I've found that having a lot of getProp and setProp handlers in use in the message path can sometimes degrade performance of property accesses. Again, the difference is in fractions of a millisecond, sometimes fractions of a microsecond, but if I limit my use of getProp and setProp to those cases where I truly need data bound to an object then I feel I'm doing a reasonable job of saving up clock cycles I can later spend on features.
So much of these things are about tradeoffs, here between developer convenience and runtime efficiency. When I'm going to make a conscious decision to impair performance, I generally try to choose the option that will also improve my own human performance by requiring less typing.
Which data store and which means of accessing it is "best" will of course depend on the specifics of the task at hand. What I've described above are some general things I often do, but my code also has many exceptions to those as well.
I sometimes think of variables when programming like some sort of bizarre multidimensional other worldly beings.