On Jul 5, 2005, at 12:04 AM, Ken Ray wrote:
I really like this idea, Dennis, but I'm not sure I like the
approach to
dimensioning, only because of Transcript's history of being able to
interpret things as strings, even if not quoted. So is:
local myArray[100,300]="false"
a boolean array, or a 5-character word array? Perhaps it's
acceptable to be
more picky about this (i.e. the above would be a 5 character word
array),
since we don't currently have a way of assigning a type, but I
think there's
a better way. For example, using your approach, if you wanted a 25
character
word array, you'd have to provide a 25-character-long string.
It seems to me that the main thing is not the *type* of data, but
for the
interpreter to know that there is a fixed size to array elements.
So perhaps
something like:
local myArray[100,300] length 5
or something like that...
Ken,
Yes, that is why I wanted to start a discussion about his before
putting in a BZ request. There is more than one approach to the
syntax even though the basic idea is the same.
It might be better to separate the declaration of the variable from
the dimension statement. Since Transcript does not care what type or
length a variable is when it is declared, no change would actually be
needed to declare its scope. That way it is easier to include the
dimension command later with non-constant arguments --which would be
better for resizable graphics. There is no reason that a variable
could not be re-dimensioned more than once --however the contents
would get reset.
I thought that it would be just as easy to specify the type implicit
in the data value that was used to initialize the string --fixed
dimension arrays have every element filled except in the case of a
string array that includes a char count which could be zero. I don't
think the user should have to know the exact internal format of the
data type chosen --unless he is writing an external. If there are
two sizes of integer formats, then perhaps they are specified a short
or long instead of 2 byte or 4 byte.
Having a variable length string type is another fine point. Does it
make sense to have a variable length string type at all, since
Transcript is already very robust in the string area. Perhaps it is
sufficient to have only a fixed number of chars that are padded out
with a "blank" char. I could go either way, but having a char count
for a string type would be more general and it would increase the
number of uses. Perhaps the length is a max of 127 or 255 characters
--only short strings would benefit from a fixed length array.
I still have a lot of questions about how different people would use
this type of array. Right now, I could use over half of the types
below in just one application that does not even use any images:
local myArray
dim myArray[ imageHeight, imageWidth ] RGBpixel=0,0,0 --how many
image pixel formats do we need?
dim myArray[ rows, columns, pages ] realNumber=0 --do we need 32 and
64 bit numbers?
dim myArray[ rows, columns ] short integer=0 --do we need 8,16,32
bit numbers? What does Rev internally support now?
dim myArray[ rows, columns ] string=20 --length initialized to 0,
good for short variable length strings
dim myArray[ rows, columns ] chars="abcd" --always 4 bytes long, good
for fixed format words
dim myArray[ rows, columns, map ] boolean=0 --compact one bit logic
arrays, bit masks
Dennis
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
