XYplorer Beta Club

(I was friendly to name this wishes )
After some tries to use arrays and giving up on problems, this time I decided to write about it. Maybe this can help to make it a bit better.

What to expect from arrays? Some examples to show what i (badly) miss:
OK: then I must debug

Stepping through.../Variables...
For an array it's first element is shown, followed by the info how many elements it has. But if the contents is too long - the most important info, how many elements it has, is lost.

Double clicking the array shows the first element again - but now only with the name of the array but without the element nbr is shown. (As if the arrray would be the contents of it's 1st element)
From double click on an array I'd expect all info about the array, maybe display of the first elements (or all if scrollable), and the ability to show any element! (Ability to display *any* element is the bare minimum.)

OK - that's a bit. And knowing Dons love for long posts I'll stop it here.

How would you assess the likelihood that these wishes will be fulfilled?

Hm - don't know about the likelihood...

...only the necessity for me.
Highest is availability as parms for functions. For me in the moment the reason to use arrays.
2nd the return from functions.
I'd expect array1[]=Array2[] isn't too hard to realize?

Debugging, i.e. info what's contained in the elements? It's a must be - if XY doesn't offer it everyone must realize it for himself.

The last examples (kind of sub-arrays) were nice to have, but rather low prio.

OK: I don't know, how many people use XY-arrays, and what they do with them. When hearing that XY-arrays are available many were glad - but then: most silence. Maybe a bit more functionality would bring more interest? It could be worth it.
(Or all use arrays, and only I have problems?)

Well, the likelihood is not so high at the moment. Priorities...

Thanks for the heads up.
("not so high" gives a bit of hope )

Sad I have to delay my use of arrays till then. (Unless I find another use.)

Thanks till then...

By the way: nobody else is using arrays and having thoughts about? Strange.

PeterH wrote: ↑03 Apr 2023 19:44 nobody else is using arrays and having thoughts about?

Well, their introduction had come with a "little" delay. In the end, I decided not to rewrite all relevant parts of my major scripts.

I do understand that.
But I hope that also today scripts are written by people - and if they think that use of arrays can help them, I think they would use them.
I have to rewrite some scrripts, as they start to not fit currrrent situations as they should. And knowing about arrays I had ideas how to start with them. But then: just what I'd need wasn't possible...

Thanks for the answer!

I'd love to see those features as well, especially arrays as parameters and return values that would make a lot of my scripts easier to maintain...
But it seems they are still a bit of a second-class citizen

Thanks for the comment!
And fine it seems you would have the same use case - if you could

Hmm, AFAIK arrays as parameters have been working for a while:

Strange! Currently I'm often working with older versions, but at least V24 - so it should be OK.

No question: will test tomorrow - no problem as you show code to compare with. If that works, and mine doesn't, I should find the cause.
As I said: for me this would be the bare minimum I need.

OK - everything's clear!

The code you supply works - but doesn't look as it *usually* should. (The parm def for function is &$array, i.e. pass by pointer, not by value.)

But more info to come:

Look at the first stmt: $a = array(...);
It shows that a function *can* return an array.
And $a *can* receive (=store) that data, i.e. the array.
Can be verrified by reading nbr of elements, and each element of $a.

A stmt not here: $b = $a;
We've just learned that $b can receive=copy=store the data of an array.
As the stmt doesn't work (test number & contents of elements!) it seems $a doesn't supply data as it should.
No question: $b must receive the same as $a before, i.e. the same as array() has returned.

The function: usually it would be test($array) - this does NOT work.
Seems to be the same as before: the supplied parm $a doesn't supply it's contents correct. (As this has to be stored in the function-local $array.)
I'm convinced: this *should* work!

In the example the function is defined with test(&$array). Here the function addresses directly $a: this works.
Haven't just tested return $array; This should work, like the return of array(...) does;

So it's clear what works, and what doesnt. And how it should be. And it seems that the missing part (array-var like $a has to supply the complete array on reference) shouldn't be too hard?

So: I think there is hope

One more point: global is defined in help as global $array[];
In the current example references to the complete array are without [].
It should be consistant. And I'd prefer the simple global $a; - though it lacks the visual identification of arrays.

That's it - as short as I could, and still exact enough. I hope

Edit: just typo

As I replied today to "Script Exchange / 2 array variables seem to be the same array", but want to continue with another view of "arrays", I think it's better to continue in this thread.

The problem I see is that arrays *seem* to be based on "variables", but it only simulates/seems to do. What do I mean?

Look at "real" variables:
$s = "I am a string"; copies a value, i.e. the string, to the variable $s.
$t = $s; copies the contents / the value of $s, i.e. the string, to $t. Easy.

$a = array(...); *seems* to do analogue: copy the value, i.e. the (complete) array that's returned to $a.
$b = $a; should just copy the value of $a, i.e. the array, to $b.
But even in stepping mode you see: $b is assigned nothing, i.e."".

*If* $a=arrray(...); means that $a can receive (=copy) an array, $b=$a; => "" would mean $a can't give it's value to copy to $b.

Then the complaint of @altoclef - his script, just shortened a bit: Even the (rudimentary) variable display on the last step; shows: $array1 and $array2 are identical, after only $array1 has been changed/filled.
And more: the explode() >>>is not able<<< to return the built array to $array1 - then it would do it by the return value; (it's a function!) but it returns it via operand &$array1, i.e.it doesn't "return" the value, but gives it to the given pointer of the operand. Why this strange method?
(I've tested: a function can not return an array!)

OK: if explode doesn't seem to be able to return the array - why does array() "seem" to be able?
(I think it's some "illegitime" logic of array(), that other functions don't have. Maybe it builds the array, and returns the pointer instead of the data? As done by operand &$array?)

I'm afraid i've guessed enough. Maybe Don can shed a bit of light on this.

Check out the fix first. Then try to shorten your post.

1) for your fix I'm convinced that you changed array() to return a pointer to a *new* created empty array, as it did before for (all) non-empty arrays.

2) short form:
a) the most basic use for variables is eg $b = $a;

b) this is not possible, if $a contains an array.

(for the same reason) a function can not return an array. (return is what the return instruction is made for.)

For me this is against all expectations, and against all consistancy of syntax.

As long it stays this way it will hinder you to add basic functions, as these mentioned above.