_ArrayAdd() function not compatable with old version

[AndyS01]

I just updated to the newest version of AutoIT and when I add a line of text containing "|" characters to my array using _ArrayAdd(), the array ends up with each element containing a part of my string broken at "|".

 

So, if I had a string like "A|B|C|D", and I did an _arrayAdd($ar, "A|B|C|D), my array then contains 6 elements:

[0] = 5

[1] = A

[2] = B

[3] = C

[4] = D

 

I see that the calling syntax in the old AutoIT version is quite different than the new syntax:

old:

_ArrayAdd(ByRef $avArray, $vValue)

 

new:

_ArrayAdd ( ByRef $aArray, $vValue [, $iStart = 0 [, $sDelim_Item = "|" [, $sDelim_Row = @CRLF [, $hDataType = 0]]]] )

 

The new syntax is not backwards compatible.

 

Sample code:

#include <Array.au3>
global $ar, $str, $outstr = ""

$str = "A|B|C|D"
$ar = stringsplit("","")

_ArrayAdd($ar, $str)

$outstr &= ubound($ar) & @crlf
for $x = 0 to ubound($ar) - 1
     $outstr &= $ar[$x] & @CRLF
Next

msgbox(0, "INFO", $outstr)

New Version info: Version 3.4.4   Jul 13 2014 20:07:38

 

Old Version info: Version 3.3.6    Dec 30 2013 15:53:31

 

[water]

What you posted is the version of SciTE.

I assume you installed the latest AutoIt version 3.3.12.0.

The Array UDF has been rewritten, the following page describes the (script breaking) changes that have been made.

[Melba23]

AndyS01,

This has been brought up and discussed before. We write the change logs to help when updating, so it pays to read them - especially when we advise that the changes are "script-breaking".

M23

[AndyS01]

I did read the release notes.  I saw that it was a script breaker but it looked like it just had additional parameters, but this is more than that.  The problem is that I have lots of source files in my library that are now broken.  I thought of creating a wrapper around _ArrayAdd() where I do a string replace of "|" characters with another replacement character/string, but the replacement character might be in the caller's string.   Also, the function hardcodes the delim char as "|", but if the system default char is something else(Opt("GUIDataSeparatorChar")), the function fails. You can't really depend on not having a string that might have several special characters.

 

(Please look at BrewManNH's comments (Posted 02 June 2014 - 04:29 PM) about this here: '?do=embed' frameborder='0' data-embedContent>>)

 

Further checking of the new library UDFs, I see more things that are deal breakers.  The real deal breaking problem is that the compiler doesn't get an error when calling _ArrayAdd(), _ArrayInsert(), etc. with old syntax.  If the delim parameters were made to be required, then I would get compiler errors if I try to use them with the old parameters.

 

My only resolution is to go back to 3.3.10.2.  It's a bummer because I won't be able to use 3.3.12.0 and above, so I'll miss out on any fixes from now on.

 

I don't understand the cavalier attitude with "script breaker" code.  If I were coding these new UDFs, if there were additional parameters and not using them would make the function produce unexpected behavior, I would make the new parameters mandatory so the user would get errors when using the old function calls.

 

[iamtheky]

My only resolution is to go back to 3.3.10.2.

 

 

you can also just keep an old version of the array UDF...   I keep it because I have a boner for arrayswap

[Melba23]

AndyS01,

We had 2 threads running when the Array library was being rewritten - no-one mentioned any problem with the new parameters at any time. We wrote a detailed changelog when the new code was released and explained carefully that certain functions in the library had been seriously amended - we even added a specific page to the Help file to detail these changes. So I totally reject the "cavalier attitude" insult you threw at us (or rather me since I rewrote this particular library) - where were you when all the public consultation was happening?.

The Array library has become much more flexible, and able to deal with 1D and 2D arrays, and all it requires is small amount of re-coding to make old scripts compatible. And if you think this is a disaster, how on earth did you manage when all the includes were split in 3.2.12.0? Anyway, if you are going to revert to an earlier AutoIt version because of this pretty small change, then you do not deserve to benefit from any future improvements and certainly have no sympathy from me.

M23

[AndyS01]

I apologize, perhaps cavalier was a little too strong.  I appreciate the time that you took to do all of this work   However, these changes marked "SCRIPT BREAKING" are not small changes.  For instance, in order to use my functions that use _ArrayAdd(), I'm going to have to write a 'wrapper' function that adds a dummy string to the caller's array, then replaces that added element with the caller's string.

like this:

func _myArrayAdd(byref $ar, $sStr)
    _ArrayAdd($ar, "~HELLOWWORLD~")
    $ar[UBound($ar)-1] = $sStr
endfunc

Then I would have to change every occurrence of _ArrayAdd in my source files, with calls to _myArrayAdd().  I searched all of my AutoIT source files and there were more than 780 files with 1 or more calls to _ArrayAdd()!!

I have not checked how many of my files contain the other calls to "SCRIPT BREAKING" changes

 

As a developer, it would make sense that if a UDF has "SCRIPT BREAKING" changes, the function would make the first added parameter mandatory. Then I would get compile errors when using these functions, forcing me to fix my code.  That way, I would not have to fix my already released scripts until I'm actually going to change them to fix bugs or add features.

 

I started using AutoIT with version 3.3.10.2, so 3.3.12.0 is the first update I had to do.  Now that I know how to adjust for new releases, it will be a lot easier.

 

As to "where were you when all the public consultation was happening?", how do I know when these changes were out for review?  Is there a mailing list?

[water]

This changes have been discussed on this forum.