>>Try the following:
>>
>>PUBLIC aPubArray[2,3]
>>aPubArray = 'Foo'
>>PRIVATE aPrivArray[2,3]
>
>The previous statement only hides any aPrivArray variable from a higher level. PRIVATE doesn't allocate the array and, after the above statement, the aPrivArray doesn't exist yet.
>
>>aPrivArray = 'Bar'
>
>Now, aPrivArray becomes a char string variable, not array.
>
No, this assigns 'Bar' to all elements of the array aPrivArray. Try:
DISPLAY MEMO LIKE aPrivArray
and you'll see the result of the assignment.
>>? DEMOARRAYERROR(@aPrivArray) && OK
>>? DEMOARRAYERROR(@aPubArray) && meltdown
>>
>>FUNCTION DEMOARRAYERROR
>>LPARAMETER aRefArray
>>DIMENSION aRefArray[4,2]
>
>Being a test program, it's not correct to reDIMENSION the parameter. This will make it to be array anyway! And this is what changes the results of your test.
>
What =really= happens is that the scope of the referenced array is hidden; a PRIVATe, which would be visible downward, scopes as a local. Unfortunately, so does a PUBLIC. The redimension would 'carry up' the chain - when the funtion returns, the array passed by reference has beeen redimensioned 'upwards' as a side-effect. The NTI entry becomes associated with a new value entry, and the old value entry is toast. The old NTI entry is hidden for the time that the parameter is visible, and by using an LPARAMETER, the PUBLIC or PRIVATE array disappears beneath the scope of the function call.
I'm not stating that this behavior is wrong; I believe that it is exactly the behavior I'd expect given what I know about the innards of VFP's variable representation; there'd be serious confusion if I could have two non-identical names referencing the same value entry visible at the same time. Imagine the confusion arising from redimensioning both the PUBLIC and the LPARAMETER-passed referenced array..."last man standing wins" is the best you could hope for, with the consequences being passed upwards in the call stack.
I do, however, believe that the side effects of pass by reference in thsi case can and do lead to an error that's really tough to debug, and not teribly descriptive; VFP assumes that the public array reference in the function is a function call because the PUBLIC's name is hidden.
>Try the following:
>PUBLIC aPubArray[2,3]
> aPubArray = 'Foo'
> PRIVATE aPrivArray
> DIMENSION aPrivArray[2,3]
> aPrivArray = 'Bar'
> ?"Call with private array:"
> = DEMOARRAYERROR(@aPrivArray) && OK
> ?"Call with public array:"
> = DEMOARRAYERROR(@aPubArray) && meltdown
>
> FUNCTION DEMOARRAYERROR
> PARAMETER aRefArray
> ?"Array length:", alen(aRefArray)
> ? aRefArray[1,1]
> RETURN
>
>This works just fine, with both PRIVATE and PUBLIC arrays.
>
Yes, but even without the redimension to confuse issues, the public reference in:
? aRefArray[1,1], aPubArray[1,1]
in the function call breaks things. The reDIMENSION is there only to cause some added confusion in the name resolution, by breaking the link between the value hidden and associated directly with the PUBLIC and the revised value definition in the pass-by-reference array.
