Hi Robert,
Antonio already ticked off most of the things to watch out for. Only a few things left unsaid after on 27. adding local [ARRAY] la(arraydim):
Numbering to his first answer:
4 ) vfp will check whether the first parameter exists or not - but if it exists it is also checked if it really is a vfp Array, otherwise error.
8 ) the ability to set all array elements with a single line without referring array element like
laMyArray = luForWholeArray
this encompasses only simple data types like strings, dates or numbers - you cannot assign an object to all array elements at once, those must be assigned to individual array elements.
9 and 10: for me one of the more illogical syntax parts in vfp, in prg code class code you use Dimension again, whereas in object.addproperty("aMyNewArrayProperty[3]" [, ValueforAllNewElements)
method plus the addproperty function with the object as first parameter.indicating dimensionality inside property name string is enough.
Here I wonder if it is enough to have a Clipper ragged array as last parameter on a undimensioned property name, but see no obstacles, as
obj.addproperty("PropertyName", createobject("MyWishedforClass")) adds complex property, which could be the ragged type
robert wrote: So would it be OK with you if the Dimension and Declare statements produce a FoxPro compatible array (as well as functions like ADatabases).
And a declaration like
orwould then produce a Clipper compatible array, that can grow with functions such as AAdd()
gets also strong yes, perhaps with new keyword RAGGEDARRAY to register when speedreading code - as long as previously written vfp code works as expected, having more code options is a benefit. Would the vartype(RaggedArray)/type("RaggedArray") be "O" with further checking the object or a new return value like "R" ? Checking Alen() probably could not differentiate between vfp and RAGGEDARRAY ?
How common is this kind of code (like the example from the help file) in your code? Would it be a problem to require people to declare the private first. We can add the @ character automatically in the compiler. We already have support for that.
If it is a problem to require people to declare the variable first then it would also be possible to mark functions such as ADatabase() with a special attribute in the runtime, so the compiler "knows" that this is a function that may create a new local and then it can automatically generate a private (or local) declaration at compile time.
On 11) I think I wrote a simple Try Catch when topic was raised a few months back which will handle creation of non-existing variable without heavy lifting, can en passant check that any existing variable really is a vfp array and otherwise throw error - Adding automatic @ / ref parameter after parse as not in vfp code for first parameter should be
easy.in same step.
If every vfp Array function is automatically wrapped with that Try Catch no real speed or other problems should crop up...
edit: rethinking a bit, as 1. parameter is a reference, perhaps not even try-catch is needed if the macrocompiler works without failure if encountering lines along
lnLines = ALINES(&tcMak, "1,2,3,5",5,",")
where tcMak might be a string parameter the compiler cannot parse in advance, as checking only is done on globals, privates and locals in that scope defined by function or method.
/edit
regards
thomas
