Page 1 of 1
[solved] Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 00:21
by PeterH
OK: short version.
Assume: $p contains the variable-name '$A3' of an array.
For both:
Code: Select all
$ele2 = *$p[2]; // copy 1 element of array
*$p[2] = 'X2'; // set 1 element of array
*$p[2]
could be interpreted 2 ways, I demonstrate them with ():
(*$p)[2] or *($p[2])
I'd expect (and wish) the first version - as the comments describe.
(The 2nd version doesn't help much, and is simple to emulate.)
For $ele2 = *$p[2]; the element, i.e. [2], is ignored: the complete array is copied.
For *$p[2] = 'X2'; it seems nothing happens. ($A3[2] is not changed)
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 11:25
by admin
Unfortunately, you are right. Man, you keep me busy. Fixed in the next beta.
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 11:36
by PeterH
Fortunatually you're going to fix it
Waiting ... can't get on till then.
Bad that I'm always doing things for the first time
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 11:49
by admin
Just to make sure, this is how it will be:
Code: Select all
! Scripting | Arrays: Dereferencing array elements did not work properly. Fixed.
$a = array("cat", "dog");
$p = '$a';
$el = *$p[1]; // get dereferenced array element
echo $el; // dog
*$p[1] = 'horse'; // set dereferenced array element
echo $a[1]; // horse
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 11:58
by PeterH
If I interpret it right it is exact what I meant = wanted!
OK: when you're ready with *everything* else, you could add the logic with ()
edit: typo
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 13:29
by PeterH
First *test* shows: this problem is solved!
Before trying in productive script:
Report a follow-up problem!
(It was there before your change - I didn't want to mix it up
)
See following example-script: if executed in stepping mode, the call to f() will only report 3 parms - the 4th is totally ignored.
(But: it *is* passed correct - it's only the stepping display! But that's irritating
)
Code: Select all
STEP;
$s3 = "D1 D2 D3 D4"; // tokens
Explode($A3, $s3, ' '); // create Array $A3
f(0, 1, 2, $A3); // XXX stepping-info for this call shows only 3 parms!
Function f($p0, $p1, $p2, &$p3) {
STEP; // function is only dummy
}
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 15:02
by admin
The source of the problem here is that XY allows $A3 and $A3[] to exist side by side as independent variables. In your code $A3 resolves to "" (empty string). In the next beta it will be shown like this in the step dialog (no mention in change log):
What should have done in your code is to make clear it's the array variable by adding []:
The step dialog then:
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 15:58
by PeterH
Isn't this a bit of syntax mismatch
For explode() + implode() the array variable is defined to *not* have []
For array() it defines that both is allowed
And now you say there's a difference between $a and $a[].
Problem for me: *the caller* decides, if a parm is string or array - the script tests that and reacts as necessary.
And in this mini-script the (caller's) parm *is* an array - no "" or nothing. (You can check it in the function!)
So no: I don't understand the explanation.
By the way I remember I wanted to ask: what happens if I assign a plain variable to an array-variable, or vice versa? I expected overwriting...
Another: can I distinguish indexed and associative arrays?
What if I add
$a['text'] to an
indexed arrray?
It seems some things are left unspecified...
I'll stop it here (for the moment)
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 16:04
by admin
Relax, you can see it as an additional default element:
Code: Select all
echo $a; // non-array-value
echo $a[0]; // 1st array value
echo $a[1]; // 2nd array value
PS:
For explode() + implode() the array variable is defined to *not* have []
The help file is
wrong here. [] is totally tolerated. I'll correct that.
Re: Problems with dereferenced access to array-elements
Posted: 07 Aug 2023 20:07
by PeterH
OK: I misunderstood that the
function definition should specify the []. (So I wrote that the function doesn't know it before being called.) But it's the parm
in the call. That relaxes a lot.
But if $a is non-array, and $a[] is array, it's strange that the function sees vartype($p3) as 'array' if called with $a.
(Don't get me wrong - it's what I want. But I still don't get the logic...)
===> stepping-display says it's (empty) string, while the function sees the expected array - strange
So what's left is problem with my understanding
Re: Problems with dereferenced access to array-elements
Posted: 08 Aug 2023 07:42
by admin
Each variable has a "base value" (to give it some name) and an optional array of values. If vartype() returns "array" read it as "has also array values". Which value is used depends on how you access the variable. If not explicitly marked as array (by adding []) the step dialog displays the base value.
Re: Problems with dereferenced access to array-elements
Posted: 08 Aug 2023 11:18
by PeterH
Thanks for the good explanation
Still I don't know why the function sees the array (this is a must), while the step dialog doesn't.
I'd say it's important that it's an array, and only "by the way" it also has a 'base' var.
For me it's "not expected". But I can live with that.
Re: Problems with dereferenced access to array-elements
Posted: 08 Aug 2023 12:48
by PeterH
Thiink I diidn't mention: tested
