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