Modify

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#2029 closed Feature Request (Rejected)

Array and variable handling / suggestion

Reported by: Shaggi Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Array Variable list nested Cc:

Description

  1. Accessing temporary arrays

This could be a cool feature, and in many cases reduce code in larger expressions. Also, it will solve the problems explained later down. Example:

Func n()
	Local $Array[2] = [1,2]
	Return $Array
EndFunc

MsgBox(0,"",n()[1])
  1. Ability to have 2 variables reference the same content.

This is already working through ByRef parameter passing, however when you return a referenced parameter it creates a copy. Example:

Global $Array[2] = ["foo","foo"]
$Array2 = n($Array)
$Array2[1] = "bar"
ConsoleWrite($Array[0] & @CRLF & $Array[1])

Func n(ByRef $Array)
	Return $Array
EndFunc

This is the same with normal variables.

  1. Nested arrays / Arrays in arrays and linked lists

Since arrays can store other arrays, why cant you access them without getting bounds errors? This seems more like a faulty parsing case than a limitation within autoit:

#include <Array.au3>
Dim $a[2]
Dim $b[2]

$b[0]="foo"
$b[1]="foo"
$a[0] = "bar"
$a[1] = $b

_ArrayDisplay($a)
_ArrayDisplay($a[1])

ConsoleWrite($A[0])
ConsoleWrite($A[1][0]) ;Error

It seems that when arrays are assigned to elements of others, they are stored as temporary variables - maybe this is related to #1? If this could be fixed, it would allow many things - like a more structured design like linked lists or better ability to write something object oriented.
As it stands now, the only way to modify the contents of an nested array (without creating a copy of the index, modifying and assigning back) is through byref parameter functions, so you can access the element. Example:

#include <Array.au3>
Dim $a[2]
Dim $b[2]

$b[0]="foo"
$b[1]="foo"

$a[0] = "bar"
$a[1] = $b

_ArrayDisplay($a)
_ArrayDisplay($a[1])
Change($A[1])
_ArrayDisplay($a[1])

Func Change(Byref $A)
	$A[0] = "changed"
EndFunc

It is possible to do it this way, however when you have a nested array (c) inside a nested array (b) in a array (a), it's near impossible to change contents of c without creating a new array - because as #2 states, a ByRef parameter returned is a new copy. And since you can only access nested arrays through ByRef parameters, you actually have to create a recursive byref function, that "dereferences" the array each time. This is a costly process, and pretty stupid. Example:

Func _C_NestChangeVal(ByRef $Obj, $Val, $Ref1 = -1, $Ref2 = -1,$Ref3 = -1)
	Switch @NumParams
		Case 5
			_C_NestChangeVal($Obj[$Ref3],$Val,$Ref1,$Ref2)
		Case 4
			_C_NestChangeVal($Obj[$Ref2],$Val,$Ref1)
		Case 3
			$Obj[$Ref1] = $Val
	EndSwitch
EndFunc

I hope this will be implemented, and since (i think) AutoIt supports it all, it shouldn't be that hard to do.

Attachments (0)

Change History (6)

comment:1 Changed 8 years ago by anonymous

+1

...and literal arrays?
Local $a = ACreate()

Func ACreate()

Return ['1','2','3']

EndFunc

comment:2 follow-up: Changed 8 years ago by trancexx

  • Resolution set to Rejected
  • Status changed from new to closed

Number 1 may seem like a good thing but really it should be this:

Func n($x)
	Local $Array[2] = [1,2]
	Return $Array[$x]
EndFunc

MsgBox(0,"",n(1))

Number 2 is not sensible request. If you want (and absolutely need) two variables referencing the same data then don't use array, use dllstruct type.

Number 3 is syntax mess considering current syntax rules for accessing arrays. Plus what's said already.

Anonymous's suggestion is bad from several aspects one of which is creating exception of rules.

Rejecting all.

comment:3 Changed 8 years ago by trancexx

Small correction. Number one will be part of new beta.

comment:4 in reply to: ↑ 2 Changed 8 years ago by Shaggi

Replying to trancexx:

Number 2 is not sensible request. If you want (and absolutely need) two variables referencing the same data then don't use array, use dllstruct type.

Number 3 is syntax mess considering current syntax rules for accessing arrays. Plus what's said already.

Anonymous's suggestion is bad from several aspects one of which is creating exception of rules.

Well i dont know, references are good for a lot of stuff imo. Looking at your old source it seems your variant supports references to others. As for three, it doesn't change the syntax in any way - only allows for direct access to these references or temporary variables, much like number 1?

Rejecting all.

:/

Small correction. Number one will be part of new beta.

good to hear you're looking at 1 though, looking forward to it.

comment:5 follow-up: Changed 8 years ago by Valik

References may be added someday but there are no plans to do so. If references are added it won't be tied to arrays, it will be a general mechanism that works with any variable.

As for accessing nested arrays... it wouldn't work how you think. I would love to add the syntax and indeed it's really no different than allowing StringSplit("a,b", ",")[1] which we now support. However, the key point in the StringSplit() example and in nested array access is that what you really access is a temporary object. Nested arrays would be read-only. Attempts to write to them would write to the temporary object which would be discarded at the end of the statement.

I know what you want to ask, can't you just make the temporary reflect back to the stored version when writing? Yes, in theory. However, that opens a can of worms because at first glance other more complex examples of using temporaries would also benefit from the temporary being reflected even though that behavior would be incorrect in those cases.

comment:6 in reply to: ↑ 5 Changed 8 years ago by Shaggi

Replying to Valik:

References may be added someday but there are no plans to do so. If references are added it won't be tied to arrays, it will be a general mechanism that works with any variable.

Sounds good.

As for accessing nested arrays... it wouldn't work how you think. I would love to add the syntax and indeed it's really no different than allowing StringSplit("a,b", ",")[1] which we now support. However, the key point in the StringSplit() example and in nested array access is that what you really access is a temporary object. Nested arrays would be read-only. Attempts to write to them would write to the temporary object which would be discarded at the end of the statement.

I know what you want to ask, can't you just make the temporary reflect back to the stored version when writing? Yes, in theory. However, that opens a can of worms because at first glance other more complex examples of using temporaries would also benefit from the temporary being reflected even though that behavior would be incorrect in those cases.

Alright & thanks - I appreciate the thorough explanation :)

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.