Arrays in Rev (long)

[Troy Rollins]

On Jul 11, 2004, at 10:35 PM, Richard Gaskin wrote:

> > In my previous world, it was nested lists... and here in RevLand?
>
> The best answer would depend on usage -- can you give us a scenario  
> for what you have in mind?
>
> Here's one option:
> <http://lists.runrev.com/pipermail/use-revolution/2002-July/ 
> 006149.html>
>

Richard, that is an excellent document, and identifies what looks like  
a much more "Revolution way" of doing things. In fact, in my current  
app, I do pretty much everything you've described there, so I guess  
I've done some things right and Rev-like after all. Now, about session  
data and relational session data... THAT I've never tried to do with a  
stack before.

Perhaps some kind of example will help after all. Let's say, I have an  
application which on launch, collects data from various sources, the  
user's system, some stack and card data, an XML feed, some remote  
images, some local images. This data has logical groupings and  
interrelationships which need to be created and maintained. As well as  
performing searches on this data the user also needs to find similar  
and related (near) groups or items.

Using the data stack method, is it sensible to create a stack, sort the  
data into it, use Transcripts powerful stack and card manipulations to  
perform session functions... and then simply never save the stack? Is  
this how the system is designed to work in the first place? A temporary  
stack as an advanced multi-dimensional variable? If this is the case, I  
think I like that much better than trying to force my own metaphor down  
the throat of Rev by trying to create multidimensional arrays inside  
something which really has no support for them. It sounds as though the  
speed should be there, as well as the multi-datatype storage....

Believe it or not, folks, these are big mental shifts if you don't come  
from a stack and card nature of programming. But, I'm trying... I want  
to understand and use "best practice" techniques.

--
Troy
RPSystems, Ltd.
http://www.rpsystems.net