Posted by Jeff Cinelli on April 11, 2011 at 07:59:02:
In Reply to: Re: Comet 32 Arrays posted by Jim Guerber on April 09, 2011 at 15:21:39:
I think specifying an initial subscript of any given number would be the ultimate way to go. That would give the developer complete flexibility.
Suppose someone was writing an application to reserve seats in a stadium. There are 3 sections with varying rows and seats. For example:
Section 1: Rows 100-120, 50 seats in each row, starting at seat #1
Section 2: Rows 200-235, 40 seats in each row, starting at seat #25
Section 3: Rows 300-350, 100 seats in each row, starting at seat #1
To be given the ability to specify a starting subscript when storing the array in a data file would be extremely convenient. Lets setup an array for the above example with a 1 byte field, to simply indicate if the seat is taken or not.
LENGTH 1 & LOCAL SECTION1$(20,50), SECTION2$(35,40), SECTION3$(50,100)
.
DATARECORD: FORMAT SECTION1$(100,1),1000*1; SECTION2$(200,25),1400*1; SECTION3$(300,1);5000*1
Formatted as such, 7400 bytes would be stored in the data file, 1 for each seat. Having the arrays correspond with a seat number is extremely convenient, rather than setting up a different 7400 byte array. To have that same convenience now, we we need to set up a 120x50 array for section 1, 235x40 array for section 2, and 350x100 array for section 3, most of which would be unused.
So, the ability to customize an array with a starting subscript, dimensioned upwards to the defined length specified in the LENGTH statement would give us ultimate flexibility.
Option 2: Leaving 100% compatibility with Comet16 (as it is now with the latest release)
It's difficult to maintain backwards compatibility with existing programs when you want to be progressive and maintain the currently developed standard. Giving Comet the ability to specify a starting element would give us the best of both worlds.
Each file can be a maximum of 1MB in length Uploaded files will be purged from the server on a regular basis.