Good idea? or not?
As VFP is now
DIMENSION ArrayName1(nRows1 [, nColumns1]) [AS cType])
DIMENSION ArrayName1(nRows1 [, nColumns1,[nDepth]]) [AS cType])
A ROTATEARRAY command to accompany this would be a nice touch.
Suggestion 2 for irregular data processing
DIMENSION ArrayName1(nRows1 [, nColumns1,[nDepth],nSHAPE]) [AS cType])
Shape being defined by number. The higher the number the more complex the shape. Imagine a soccer ball filled with data and revolving in memory.
Some say that there are ways to do the same thing with more power and flexibility with tables and relationships natively.
What do you think?
Suggestion 1 is really for n-dimension arrays, correct?
Suggestion 2 involves much more complex structures that surely would need methods to manipulate it, so I wonder if this isn't better implemented with a class...-- Steven Black
I've been considering the developing of a class that might address this. The multi dimensional array was part of TRS 80 basic back in 1977. Maybe it's just an antique now.
I think the whole purpose of an array is to represent a (part of a) table in memory. For that, it only needs columns (for fields) and rows (for records). A three dimensional array does not have any correspondance to one (or more) tables(s), since you aren't guaranteed a 1-to-1 correspondence between tables. The concept of " Sparse -ness" is one of the things that makes RDBMS's so powerful, so That's why I believe the programmers behind xBase / VFP have never put in 3+ dimensioned arrays. After all, in the past, memory could be consumed very quickly with instantiating a 3+ dimension structure. Certainly, there are cases where small sizes of the dimensions can make such an array manageable, however, it isn't a commonly necessary use-case. Many Dimensioned Array Class - ?wgcs
Category VFP Commands
( Topic last updated: 2004.04.24 04:26:56 PM )