Arrays in Rev (long)

[Richard Gaskin]

Troy Rollins wrote:

 > 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>
 >
...
 > 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?

I'm a big fan of going with the grain of whatever language/object model 
I'm using.  I try to rely on inherent objects and functions whenever 
possible, for the speed and robustness benefits you describe.  The fewer 
lines I write, the greater the proportion of stuff happening in the 
engine which is where the real power is.  Compared to Scott Raney I'm a 
crappy programmer, but if I offload a lot of my work onto the engine he 
created I sometimes get mistaken for brilliant. ;)

As a side note, remember that you can get the names of all cards of a 
stack in one call ("the cardnames of stack <stackName>"). Coupled with 
one-liners for getting the customKeys of any property set of the stack 
or any of the cards within it, you get some pretty quick and fairly 
efficient indexing using native objects for generic storage.

 > Believe it or not, folks, these are big mental shifts if you
 > don't come from a stack and card nature of programming.

Oh, I believe it:  having multiple sets of custom properties in a given 
object is unique to Rev, as is the cardNames function.  Having come from 
other xTalks these were hard for me to get used to, but once I unlearned 
my old ways I became quite enamored of them.

 > But, I'm trying... I want to understand and use "best practice"
 > techniques.

An old mentor used to paraphrase Voltaire by telling me, "Best is the 
enemy of results." ;)

One of the most liberating things about Transcript is also among its 
most frustrating:  it's so flexible, there are many, many ways to solve 
a given problem.

I tend to code with one eye on the clock, attempting to edge ever closer 
to the Holy Grail balance of delivering the features of a 1.0 at a good 
cost while being mindful of the costs of adding new features for v2.0 
and beyond.  As a result much of my code is not the tightest nor does it 
adhere to many formal ideas of what may or may not constitute good code.

For any given task there may be better ways of doing things; I'm still 
learning new tricks every day.  All I have to offer at the moment is 
what I've used in the past to get working software out the door in a 
reasonable time frame with minimal support costs.  Your mileage may 
vary; contents may settle during shipping.

One nice thing about using stacks for storage, though:  you're always 
only one line away from saving that data if you ever need that somewhere 
down the road.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev