Arrays in Rev (long)
Troy Rollins
troy at rpsystems.net
Mon Jul 12 13:25:43 EDT 2004
On Jul 12, 2004, at 12:58 PM, J. Landman Gay wrote:
> Global and script-local variables have always been enough, I've never
> needed anything else.
Yes, thanks. I've become a big fan of script locals myself. I've
learned to consider them like "object properties" once I realized they
were persistent. I tend to use the "virtual custom property" method of
retrieving them from outside the script they belong to, treating
"getProp" and "setProp" as... well, "getters" and "setters" in OOP
terms.
The text based longer-term storage approach I've considered as well.
Long term storage is more a case-by-case issue, I guess. My primary
reason for polling the group was to determine how best to store,
maintain, and work with, complex, associated, session data. Outside of
Rev, the other tools I have used may be considered "less flexible", but
the generic technique to use is generally clear. Multi-dimensional
arrays. Inside of Rev, while "more flexible" it is less clear.
I'm currently using very limited globals (generally as arrays), script
locals, sometimes as "singles", other times as arrays, and other times
as multi-line data. But it occurred to me that some data handling
techniques are not best served by any of these conventions, at least,
not without employing some serious chunking techniques which emulate
more complex list mechanisms... but then, that gets a bit "messy", at
least in comparison to alternate languages - or more-so, at my
admittedly somewhat limited level of comprehension.
So, it further occurred to me that leaving the inherent stack
mechanisms out of my list of data storage tools for session data might
be limiting my best choice (at times.)
Sincere thanks to all who've contributed any thoughts at all. If
nothing else, it helps to shine some light on areas that are not
altogether clear (to me), as one tries to move from intermediate to
advanced.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
More information about the use-livecode
mailing list