Modularity: Local outside any function: modularity

[willichan]

Ever tried the same scenario using a map instead of array? Guess you'll like it.

​Haven't used it in anything production yet.  Have maps made it out of beta yet?  They would be a nice improvement over keeping track of array element numbers.

[FaridAgl]

That's stable enough to be used, as far as I know.

I'm using it frequency, with no problem. 

[Guest]

I have not read the whole thread but I want to comment about this:

I could declare all the control variables as Global, but globals should be aoided where possible.

 

This is true but not always. I also thought so but there is a scenario which avoid global variables will not give you too much.

It will make it even more difficult and you will not get something worth enough back..

I will demonstrate to you the case:
If you have code that have function1 , function2 and more and function1 will always be activated so before function1 the script exit (I mean that the script not run without function1), Then in function1 there is no big reason to avoid globals.

The main reason why use locals is because with locals when the function ended, the memory is cleaned. this is necessary because the script keeps running after the function end. but what if not? in this case (the script exit after the function ended) the memory of the Variables in that function will be cleaned anyway.
so in that case you have only 2 reasons to Avoid globals:

 

1) If you don't sure that in future you don't going to do change that function1 will not run always..
2) You don't need to name the vars with special names (start with g_ or/and the function name..)

If 1) is False for you then in that case I may suggest to less avoid globals (in that function only).

The value you get as return is that you don't need to work hard with parameters in other functions that communicate with function1.. I don't know how to explain more but I hope you understand what value I mean.

 

Some might say that it is wrong to write such code in a function  instead of writing it directly.

They may be right .. but when I write some app, I building it in parts. parts = functions.
That  how you do the something that easier to debug and change later. so using function is  almost always a good thing even if the code in the function should run always in any case..

Edited May 13, 2015 by Guest

[SyDr]

That's stable enough to be used, as far as I know.

I'm using it frequency, with no problem. 

​https://www.autoitscript.com/trac/autoit/ticket/2955

https://www.autoitscript.com/trac/autoit/ticket/2915

 

#AutoIt3Wrapper_Version=Beta

HotKeySet("{ESC}", _Exit)

While True
    Test() ; wait a litle bit
WEnd

Func Test()
    Local $Map[]
    For $i = 1 To 10000
        $Map["0"] = $Map
        MapRemove($Map, "0")
    Next
EndFunc

Func _Exit()
    Exit
EndFunc

 

[FaridAgl]

Thank you.
Whay should you even try doing this?

$Map["0"] = $Map

 

[SyDr]

There is no reason. You can use any other value (but will need to wait longer to see problem).

Basic idea is that memory, allocated for map elements will not be returned to you. Even if that is local map.

Func Test()
    Local $Map[]
    MapAppend($Map, 0)
EndFunc

 

[Guest]

I really like this new feature(Map Variable ).

I can not test it now.

 

Does the autoit stripper  supports stripping the string inside the map variable?

I mean that it change this for example:

$Map["varname"]

 

To something like this:

$a["b"]

 

 

Edited May 20, 2015 by Guest

[jchd]

Why would stripper do something as dumb as that? This is programmers' data, not arbitrary variable names.

[Guest]

I do not understand why this is stupid. These strings in Map[] are sub-variables(That's how I call it). each variable is represented by easy to read name(which is the string inside Map[*]),  which is usually a long name. just like normal $var.

When the script is compiled you anyway should not see these the names. but these name are usually long and this affects the performance.
So why not change also these sub-variables to short names before compiling?

I do not see why this is stupid. Or I missing something about map variable?

 

What do you mean by this ?

This is programmers' data, not arbitrary variable names.

Edited May 20, 2015 by Guest

[jchd]

The identifiers thru which map entries are inserted/updated/deleted can very well come from some external source. Renaming/changing them arbitrarily would break everything down. Just like a file path/name isn't the toy for stripper to play with.

[Guest]

The identifiers thru which map entries are inserted/updated/deleted can very well come from some external source. Renaming/changing them arbitrarily would break everything down. Just like a file path/name isn't the toy for stripper to play with.

​OK. I got it.
But if I want to use Map  variable as internal use only(so the script  does not take something from external source) then everything should be fine with this(As long as the variable used internally).

So maybe should be an option to tell to stripper which map variable it is allowed to strip it's sub-variables. and by default the stripper will not strip it's sub-variables.

And also an option to strip any map variable(I mean the sub variables in the map) and this option is off by default.

 

Hope you understand

I think it's a good idea

Edited May 20, 2015 by Guest

[jchd]

Looks like a rape to me. If a tool does that to any of my source I'll turn to a different language.
 

Local $s = "abc"
Local $m[]

$s &= "def"
$m['abcdef'] = 123

ConsoleWrite($m[$s] & @LF)

 

[jvanegmond]

We're probably better off investing time solving the problems in AutoIt than putting more effort into the stripper anyway.

[jchd]

So true!