Will Associative Arrays be coming?

[Morthawt]

I have a friend learning Python and he asked me if AutoIt has Associative Arrays (Dictionaries) and if I could write something in AutoIt to help him. Firstly, I never even heard of that kind of array and I found some reference from a couple years or so ago saying it was in the beta. Is that still in the pipeline to come into the final release of AutoIt?

[water]

Maps is what you are looking for - but it is only available with beta releases of AutoIt at the moment. If it will ever make it into production? I 'm not sure

Good reading:

 

[BrewManNH]

They're already here, just not natively.

https://www.google.com/search?newwindow=1&source=hp&ei=TsucXKKlE-OHggfxz4DgBg&q=associative+array+site%3Aautoitscript.com%2Fforum&btnK=Google+Search&oq=associative+array+site%3Aautoitscript.com%2Fforum&gs_l=psy-ab.3...1848.14368..14613...0.0..0.333.3369.44j1j0j1......0....1..gws-wiz.....0..0j0i131j0i22i30j0i22i10i30j33i160j33i299.ne_lCZ7MSbQ

 

[TheDcoder]

Scripting.Dictonary is also a good candidate for associating variables with strings, shame no one has made a proper UDF wrapping it yet (that I know of)...

[LarsJ]

Do you really need a UDF for an object with 5 methods and 5 properties? It shouldn't be that hard.

A UDF in an interpreted language such as AutoIt for a small object such as Scripting.Dictonary usually has great impact on performance.

And this is important because Scripting.Dictonary often is used to handle performance issues.

[iamtheky]

5 minutes ago, LarsJ said:

Do you really need a UDF

in case the answer is yes, i totally dove this rabbit hole

 

[TheDcoder]

@LarsJ For me the beauty of AutoIt is that it is simple to create UDFs to wrap any slightly complex tasks (like handling objects)  in a simple function call, performance doesn't really matter most of the time if you are using an interpreted language, and I don't agree that it matters in this instance... _ArraySearch would still take up a lot of time than the overhead of wrapper functions will ever take up

@iamtheky I do remember your UDF, you bought it up in one of my topics about maps

I have gone searching for that on several occasions, but it is elusive, never managed to find it when I needed it...

It could be polished but it is usable in the current state

[LarsJ]

My point is that I don't want to use _ArraySearch at all. I want to save the values directly in the Scripting.Dictonary object and search directly in the object. Scripting.Dictonary is implemented in a DLL file. When you are searching, it's done in compiled code. It'll be 1000 times faster than _ArraySearch (in a very round number). If Scripting.Dictonary is implemented in a UDF, it'll only be 100 times faster. Why should I be happy with 100 times faster code when I can get 1000 times faster code?

If you're searching for Scripting.Dictonary in the forums you'll see that in many cases it is in fact used to optimize AutoIt code.

AutoIt is pretty much a simple and easy to use language (probably also a little bit dirty, I certainly won't call it beautiful). At the same time, it contains all the techniques needed to create as complex code as you can ever imagine only limited by the skills of the coder. Why not take advantage of these techniques to make AutoIt even more useful but not least to make it more interesting and exciting for experienced coders?

Edited March 29, 2019 by LarsJ

[TheDcoder]

4 hours ago, LarsJ said:

My point is that I don't want to use _ArraySearch at all. I want to save the values directly in the Scripting.Dictonary object and search directly in the object. Scripting.Dictonary is implemented in a DLL file. When you are searching, it's done in compiled code. It'll be 1000 times faster than _ArraySearch (in a very round number). If Scripting.Dictonary is implemented in a UDF, it'll only be 100 times faster. Why should I be happy with 100 times faster code when I can get 1000 times faster code?

That is perfectly fine and acceptable, if you have the technical know-how and are willing to put in effort to write code with fewer layers, then that is a good thing in any imaginable way. But that is not my point at all!

Using the raw implementation is often not that easy, especially for beginners. And since how AutoIt is meant to be a simple language, it is natural for it to have many wrapping functions, just look at the huge library of WinAPI UDFs. Most of those implementations are not optimized, but what they lack in performance make up in ease of use

Most of the time the average AutoIt coder would look at how to accomplish a certain task, rather on how to accomplish it in the most efficient way using the direct APIs

In my opinion, the AutoIt community largely owns up to the amount of UDFs it has. That is one of the beauties of the language, it is easily extensible.

4 hours ago, LarsJ said:

If you're searching for Scripting.Dictonary in the forums you'll see that in many cases it is in fact used to optimize AutoIt code. 

I am not contesting this fact

4 hours ago, LarsJ said:

AutoIt is pretty much a simple and easy to use language (probably also a little bit dirty, I certainly won't call it beautiful)

I gracefully disagree, it is what you make of it. Beauty is what you make of it, if you can write code which is easy to understand and is very organized, then it is beautiful in that manner. UDFs help achieve that by wrapping "dirty" functions calls (especially DllCall) into a consistent set of functions

[iamtheky]

Portability, speed of authorship, and the ease with which you can move data into various shapes is where i find the beauty.

Speed of execution is the least of my concerns when i start an .au3.  And if you are going to do all the legwork, why try and bring that back through an interpreter?

[junkew]

If its for education there are many ways to implement and it really depends on requirements, speed etc.

Need some time to find out if a big /large string with name/value pairs and search will beat an dictionary or array on speed

 

#include <AutoItConstants.au3>
#include <StringConstants.au3>
#include <Array.au3> ; Required for _ArrayDisplay() only.

$dictionaryString="New York City:8550405, Los Angeles:3971883, Toronto:2731571, Chicago:2720546, Houston:2296224, Montreal:1704694, Calgary:1239220, Vancouver:631486, Boston:667137"

$dictionaryString=StringReplace($dictionaryString,", ",",") ;~ To easy have it readable just replace it
$dictionaryString=$dictionaryString & ","    ;~ to simplify regex

dim $aa[2]
$aa[0]=stringregexp($dictionaryString,"(.*?):.*?,",$STR_REGEXPARRAYGLOBALMATCH)  ;~ Keys
$aa[1]=stringregexp($dictionaryString,".*?:(.*?),",$STR_REGEXPARRAYGLOBALMATCH)  ;~ Values

consolewrite("Population " & _getValueByKey($aa,"New York City") & @CRLF)
consolewrite("Population " & _getValueByKey($aa,"New York City 2") & @CRLF)
consolewrite("Population " & _getValueByKey($aa,"Boston") & @CRLF)

;~ Or get it directly from the String
$result=stringregexp($dictionaryString,"Chicago:(.*?),",$STR_REGEXPARRAYGLOBALMATCH)  ;~ Values
_ArrayDisplay($result)

;~ Simple sequential search
func _getValueByKey($a, $v)
    $x=UBound($a[0], $UBOUND_ROWS)
    for $i=0 to $x-1
        if (($a[0])[$i]=$v) Then
            return ($a[1])[$i]
        EndIf
    Next
    return "Error"
EndFunc

 

[TheDcoder]

The latest update is that the Map datatype is as good as dead, according to @jchd it is deprecated and here is something Jon mentioned in the private MVP forum:

11 minutes ago, Jos said:

Quote from a statement made by Jon in a private forum:

Quote

Well IIRC Map is fundamentally broken due to the way variables work in AutoIt.

So he won't be including it as it is, but it did stay in Beta for the moment. Don't hold your breath though to get this fixed and included.

Source: