Arrays

[Richard Robertson]

Associative arrays are a little more expensive than regular arrays both to maintain in memory and to iterate.

I also want to know why any language "needs" associative arrays.

[James]

Associative arrays are a little more expensive than regular arrays both to maintain in memory and to iterate.

I also want to know why any language "needs" associative arrays.

Who knows. Some times it makes it easier for lazy programmers - alas my self, but you can do without them.

We all have.

[Arion]

I don't like the use of the word "fixed". It's not a bug, or a problem with the language, it's something that's not implemented.

Is there a particular reason you need associative arrays and none of the workarounds work? This is something that isn't really necessary in my opinion. php is something different, as it manages large webpages, often with different scripts doing different jobs that need to store globals etc.

Mat

Or the word "immediately" for that matter.

Therein lies the difference, you don't see it as a bug, I do...

On that note, I have been looking at the plugins SDK and, once I figure it out, I plan to add the functionality myself.

@JamesBrooks: That is a discussion for another time.

Edited November 23, 2010 by Arion

[Richard Robertson]

Not having associative arrays is not a bug because there is no existing code that does not work. Bugs are existing code that does not work. What you have is a feature request which will continue to be ignored.

[MvGulik]

I have been looking at the plugins SDK and, once I figure it out, I plan to add the functionality myself.

looking forward to it.

@RR

Bugs: also do work, just not as intended. Ergo: Unintentional (and usually very useless) features.

Edited November 23, 2010 by MvGulik

[Mat]

Therein lies the difference, you don't see it as a bug, I do...

Therein lies the problem.

You quoted my post yet didn't answer my question - I can't think of a single instance where you would need an associative array. Yes I'm sure it would be nice from time to time, but that's not a good enough reason to implement it. As said already, php and AutoIt have very different aims, and are rarely used for the same purpose.

The only way you are going to get to buy it is when you can give an example that requires dictionaries.

[Arion]

First off, IMHO good array support should be a requirement. I'm writing a GUI right now where they would make a tremendous difference, but, enough of the complaining. Since it's not supported natively, I am working on a UDF which will create a maintain an array registry, without the need for resizing or declaring arrays. Once the plugin SDK gains more support, I'll re-write it as a C++ plugin instead.

[Richard Robertson]

There hasn't been any progress on the plugin system for a very long time. I don't expect to see any either.

If you really need an associative array, just use the scripting dictionary object like everyone else does.

Edited November 24, 2010 by Richard Robertson

[Melba23]

Arion,

Or perhaps nutster's excellent UDF.

M23

[Arion]

@Melba: Looks good from what I've seen, but it's still more work than it should be. The phrase 'Set it and forget it...' comes to mind.

[Valik]

...but it's still more work than it should be.

What an atrociously stupid thing to say. Everything ever in the history of ever is "still more work than it should be". Got a machine to automatically suck your dick? The fact that you have to put your dick in it is still more work than it should be.

As for this gem:

First off, IMHO good array support should be a requirement

AutoIt does have good array support. You just have a warped sense of what qualifies as good array support. You are implying strings must be a valid index before array support is "good. I could argue that arrays are only good if they take any first-class object no matter the type. In other words, opinions are pointless, especially those that come off as insulting. Just because something is different does not mean it is bad or wrong.

[czardas]

AutoIt is the first scripting language I ever tried. I'm happy that it is not bloated with unnecessary features that can easily be created using the native functions. I think it makes learning more interesting, and perhaps helps me, as learner, to become more flexible.

Edited November 27, 2010 by czardas

[danielkza]

(Some random thoughts on the subject, if they are of interest to anyone.)

I like many things in AutoIt, but unfortunately, array support is not on the same level as everything else.

Dim/ReDim is cumbersome and slow, and keeping track of sizes all around is not very pleasant.

The inconsistent use of Ubound() and embedded sizes in the core and UDF is a pain in the ass. Array slicing could fix it quite easily, and it would have saved me quite some time spent coding boilerplate in many other situations.

I learned to live with it already, but if any major, breaking updates to the language are to be, this would be the area that I'd like to see improved the most.

Associative arrays would also be nice, but they have their culprits that would have to be well thought out before even thinking about including them in any language, specially one that is already in use like AutoIt. Getting them half-baked is much worse than letting people implement their own as they please. Two examples of implementations come to my mind, that you OP should think about a bit.

Python IMO got them right: lists (and tuples) are fast and simple, and can interact with dictionaries quite easily through iterators or functional operators. But you can keep them completely separate, pretending one of them doesn't exist, if you wish. Or you can nest them in any convoluted manner your twisted mind can come up with. All on you.

PHP, on the other hand, is quite a mess: you never know what might happen when you mix integer and string indexes. If you're unlucky enough, a "0" will be cast to an integer, and you'll never see something's wrong until it bites you in the ass. There's no way to avoid their problems, even if you don't care about their benefits at all. Somebody will end up quite frustrated, whether yourself or the next maintainer.

Edited December 4, 2010 by danielkza

[Valik]

Lua got it right with tables. It's the only list type in the language. Anything can be a key, anything can be a value. Even tables. You can store a table in a table value with a table index if you want. It's insane yet intuitively flexible. It's better than Python in many ways.

[jvanegmond]

Lua got it right with tables. It's the only list type in the language. Anything can be a key, anything can be a value. Even tables. You can store a table in a table value with a table index if you want. It's insane yet intuitively flexible. It's better than Python in many ways.

Don't know about Python, but +1 for Lua tables. As you said, strangely intuitive. And impressively fast too, you'd expect them to become slow because they're so flexible, but they're not at all.

[Eugenii]

And impressively fast too, you'd expect them to become slow because they're so flexible, but they're not at all.

Is there any chance to get such speed with AutoIt?

I tried to compare array processing speed versus another great tool based on Lua:

test={};
test2={};
for count = 1, 150000 do
   if (count==10000) then
      test[count]={101,102,103,104,105,106,107,108,109,110}
   else
      test[count]={50,51,52,53,54,55,56,57,58,59};
   end
end
for count = 2, 150000 do
   test[count-1]=test[count]
end
for count = 1, 149999 do
   test2[count]=test[count];
end
for el in pairs(test2) do
   if test2[el][1]==101 then
      res2=el
   end
end

VS

expandcollapse popup

Dim $test[150000][10]
Dim $test2[149999][10]
For $a=0 To 149999
If $a=9999 Then
;~   For $x=0 To 9
;~       $test[$a][$x]=101+$x
;~   Next
     $test[$a][0]=101
     $test[$a][1]=102
     $test[$a][2]=103
     $test[$a][3]=104
     $test[$a][4]=105
     $test[$a][5]=106
     $test[$a][6]=107
     $test[$a][7]=108
     $test[$a][8]=109
     $test[$a][9]=110
Else
;~   For $x=0 To 9
;~       $test[$a][$x]=50+$x
;~   Next
     $test[$a][0]=50
     $test[$a][1]=51
     $test[$a][2]=52
     $test[$a][3]=53
     $test[$a][4]=54
     $test[$a][5]=55
     $test[$a][6]=56
     $test[$a][7]=57
     $test[$a][8]=58
     $test[$a][9]=59
EndIf
Next
For $a=1 To 149999
;~ For $x=0 To 9
;~   $test[$a-1][$x]=$test[$a][$x]
;~ Next
$test[$a-1][0]=$test[$a][0]
$test[$a-1][1]=$test[$a][1]
$test[$a-1][2]=$test[$a][2]
$test[$a-1][3]=$test[$a][3]
$test[$a-1][4]=$test[$a][4]
$test[$a-1][5]=$test[$a][5]
$test[$a-1][6]=$test[$a][6]
$test[$a-1][7]=$test[$a][7]
$test[$a-1][8]=$test[$a][8]
$test[$a-1][9]=$test[$a][9]
Next
For $a=0 To 149998
;~ For $x=0 To 9
;~   $test2[$a][$x]=$test[$a][$x]
;~ Next
$test2[$a][0]=$test[$a][0]
$test2[$a][1]=$test[$a][1]
$test2[$a][2]=$test[$a][2]
$test2[$a][3]=$test[$a][3]
$test2[$a][4]=$test[$a][4]
$test2[$a][5]=$test[$a][5]
$test2[$a][6]=$test[$a][6]
$test2[$a][7]=$test[$a][7]
$test2[$a][8]=$test[$a][8]
$test2[$a][9]=$test[$a][9]
Next
For $a=0 To 14998
If $test2[$a][0]=101 Then $res2=$a
Next

Lua is done in ~374 ms while AutoIt in ~3203. If I use nested For...To...Next to assign array element values, it takes even more time ~4506 ms. While increasing the second dimension size, the processing time also increases significantly in AutoIt. In Lua it increases slightly.

At this moment the only solution, as I see, is to combine both scripting engines: to use Lua for array processing and AutoIt for all other work.