What's the full extent of the usefulness of $Variable()

[guinness]

Can be used to shorten the code needed to shorten a long and repetative usage of a potentially long named function, to variableize it rather than make a shorter named function that passes the parameters to the long names function.

No! That option shouldn't be considered.

If you use Obfuscator and the /OM paramater then this will shorten user-defined function names. Using this feature because you can shorten MsgBox to $m is just the wrong way to look at this, please re-read Melba23's example usage again.

Edited December 30, 2013 by guinness

[Morthawt]

I did, which is why I wrote the second thing based on what I got from his example. I know it may not be a "good" usage of the new functionality but it does serve that purpose unless, I guess, you run the obfuscator with that option.

It would help for new features like this that good examples and descriptions are supplied so that people can get to grips with it right away. Without coming here and making 100's of posts I would never understand the true benefit and I guess even now I do not truly "know" why it is beneficial except in the instance where the function that is accessed from the parameter of the other function will always use the same context and number of parameters and so the original function can run another function based on the one supplied as a parameter of the original function. If there is more to it than that I don't get it. Without the understanding it is just another unknown thing.

EDIT: I checked the possible obfuscator parameters and nowhere is there any mention of /OM

Edited December 30, 2013 by Morthawt

[guinness]

Doc >> http://www.autoitscript.com/autoit3/scite/docs/Obfuscator.html /OM - Generates a much smaller obfuscated file by substituting function and variable names with unique 3-character tokens

Also, if you understand the purpose of Call(), then this will make more sense as to the usage of this feature.

Edited December 30, 2013 by guinness

[Morthawt]

That URL is a dead one, error 404. So can you explain in simple terms the extent of the improvement to functions now that they can be accessed as a variable? I have read the example that was given and it does make sense, although is a limited use due to the parameters having to be the same context etc.

Edited December 30, 2013 by Morthawt

[Melba23]

Morthawt,

If you do not understand the usefulness of a function or functionality in AutoIt then just do not use it. You already limit yourself by not running UDFs so not using another part of the language should not be a problem to you in the slightest.

And if your SciTE Help file does not mention the /OM parameter for Obfuscator I suggest you update your SciTE4AutoIt3 package because it certainly appears in mine.

M23

[guinness]

That URL is a dead one, error 404.

Fixed link above.

I and Melba23 have pretty much explained this feature. If I explain any more then I am just repeating what has been said. If you use Call() then you will understand the usage of this.

[Morthawt]

Thanks. As for the /OM I was referring to the part where you set those options, it lists all the options available to you and there is no mention there. I have not checked for an entry in the manual because everything (I thought) was listed right in front of me when I am at the part to type in the parameters for it on the compile screen.

[trancexx]

@melba,

Your example shows how the new way to use a function can work but it doesn't show any advantages. To use 

$hFunctionToCall($sFile) ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

you would have to know what parameters should be passed to the function, ie know what the function is, and so you would be doing the same as writing

_Functiontocall($File)

so when would you want to use the new feature? There would need to be a requirement to call a function without being able to predict what that function would be at design time. Since that is easily covered using conditional statements the use of the new feature is not at all obvious to me yet.

This is all true. That's why the feature in its current form has limited usage and it's very hard to justify adding it to the languge by providing super-useful example, though I haven't seen very good effort to even do so. Better examples can be written.

I have posted about this before but somehow my postings make few people very nervous and they allways fail to see the points I make. Few threads got locked very soon afterward with me being accused for different atrocities (forgive me for the lack of better term).

The main problem with the feature is absence of other naturally expected features Jon removed after cunsulting himself with people who unfortunatly lack general programing knowledge. Adding FuncName() function to the language after some time was the doom of logic that showed complete misunderstanding of concepts and idea behind the feature that had potential to give new unseen power to the language. The feature was accompanied by existence of closures, subroutines, inlined and nested functions and form of anonymous functions. All removed because people who were the most experienced users (yeah right) couldn't fully understand them and follow the changes. Didn't want to, better said.

Consultation done with "friends" first instead of colleagues resulted in demand on me (being colleague) to remove one extraordinary new feature that was the fundament of new AutoIt, damn optional dollar prefix for variables, the thing that was giving syntax sense to the code.

Today I see that according to one developer and one forum moderator this feature exists so that you can safely use some obfuscator tool because variable is not string. OMG. I guess that's what Jon wants. And what he wants is really all that's important.

Better examples can be written martin.

[Morthawt]

This is all true. That's why the feature in its current form has limited usage and it's very hard to justify adding it to the languge by providing super-useful example, though I haven't seen very good effort to even do so. Better examples can be written.

I have posted about this before but somehow my postings make few people very nervous and they allways fail to see the points I make. Few threads got locked very soon afterward with me being accused for different atrocities (forgive me for the lack of better term).

The main problem with the feature is absence of other naturally expected features Jon removed after cunsulting himself with people who unfortunatly lack general programing knowledge. Adding FuncName() function to the language after some time was the doom of logic that showed complete misunderstanding of concepts and idea behind the feature that had potential to give new unseen power to the language. The feature was accompanied by existence of closures, subroutines, inlined and nested functions and form of anonymous functions. All removed because people who were the most experienced users (yeah right) couldn't fully understand them and follow the changes. Didn't want to, better said.

Consultation done with "friends" first instead of colleagues resulted in demand on me (being colleague) to remove one extraordinary new feature that was the fundament of new AutoIt, damn optional dollar prefix for variables, the thing that was giving syntax sense to the code.

Today I see that according to one developer and one forum moderator this feature exists so that you can safely use some obfuscator tool because variable is not string. OMG. I guess that's what Jon wants. And what he wants is really all that's important.

Better examples can be written martin.

Can you write a better example? Also, you were saying something to Martin? Who is Martin?

[czardas]

The feature was accompanied by existence of closures, subroutines, inlined and nested functions and form of anonymous functions.

 

I do not wish to sound undiplomatic, but there is a lot to absorb in this sentence. Theory and methods interest me, although I am aware of my own limitations as a hobbyist. As regards the use of this new feature, there's a few things I would like to try but I haven't had time yet.

Who is Martin?

 

Martin is a very clever guy.

[guinness]

I had to write documentation about this feature because it was never documented when first added to the language. I see this conversation as over now, because once again their opinion has spewed over into the conversation. Shame.

Edited December 31, 2013 by guinness

[Morthawt]

Well to get on a lighter note and back on topic. What are the things you enjoy about the fact of functions being a first class object? What can you do now that you had problems with or never were able to do that you are now able to do?

[martin]

Here is an example where it could be argued that using variables for function names makes for simpler code.

expandcollapse popup

#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=C:\Users\Martin\Documents\MG AutoIt\play\varFunc1.kxf
$Form2 = GUICreate("Form2", 376, 287, 538, 208)
GUISetFont(10, 400, 0, "MS Sans Serif")
$Input1 = GUICtrlCreateInput("", 80, 8, 121, 28)
$Label1 = GUICtrlCreateLabel("Input", 32, 8, 40, 24)
$Button1 = GUICtrlCreateButton("square", 232, 8, 107, 25)
$Button2 = GUICtrlCreateButton("cube", 232, 50, 107, 25)
$Button3 = GUICtrlCreateButton("square root", 232, 92, 107, 25)
$Button4 = GUICtrlCreateButton("cube root", 232, 134, 107, 25)
$Button5 = GUICtrlCreateButton("invert answer", 232, 176, 107, 25)
$Input2 = GUICtrlCreateInput("", 80, 176, 121, 28, BitOR($GUI_SS_DEFAULT_INPUT,$ES_READONLY))
$Label2 = GUICtrlCreateLabel("answer", 13, 178, 58, 24)
$Label3 = GUICtrlCreateLabel("", 32, 224, 310, 24, $SS_CENTER)
$Checkbox1 = GUICtrlCreateCheckbox("use function variables", 32, 88, 153, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

const  $sMethod[2] = ['Conventional','using functions as variables']

Global $aFuncs[5] = [funcBut1, funcBut2, funcBut3, funcBut4, funcBut5]

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit
        case $button1 to $Button5
            if GUICtrlRead($Checkbox1) <> $GUI_CHECKED Then
                method1($nMsg)
            Else
                method2($nMsg)
            EndIf


    EndSwitch
WEnd

Func method1($msg1);using conventional logic<<<<<<<<<<<<<<<<<<<


    Switch $msg1
        Case $Button1
            funcBut1($sMethod[0])
        Case $Button2
            funcBut2($sMethod[0])
        Case $Button3
            funcBut3($sMethod[0])
        Case $Button4
            funcBut4($sMethod[0])
        Case $Button5
            funcBut5($sMethod[0])
    EndSwitch

EndFunc   ;==>method1

Func method2($msg1);using function names as variables<<<<<<<<<<<<

$aFuncs[$msg1 - $Button1]($sMethod[1])

EndFunc   ;==>method2


func funcBut1($style)
    setAns(GUICtrlRead($input1) ^2,$style)
EndFunc

func funcBut2($style)
    setAns(GUICtrlRead($input1) ^3,$style)
EndFunc

func funcBut3($style)
    setAns(GUICtrlRead($input1) ^0.5,$style)
EndFunc

func funcBut4($style)
    setAns(GUICtrlRead($input1) ^(1/3),$style)
EndFunc

func funcBut5($style)
    setAns(GUICtrlRead($input2) ^ -1,$style)
EndFunc

func setAns($Res, $sText)
    GUICtrlSetData($input2,stringformat("%8.3f",$Res))
    GUICtrlSetData($label3,$sText)
EndFunc

[czardas]

Well I had a little play with it. I think it's useful.

;

Global $gCurVal  = 0 ; Nothing happened yet

$gCurVal = 1 ; If this happens

If $gCurVal Then $gCurVal = RandomVal ; then this line is invoked

ConsoleWrite($gCurVal() & @LF)

Func RandomVal()
    Return Random(0, 1, 1)
EndFunc

;

Not that this demonstrates anything specific. It's a nice feature which was originally intended to be just one piece of a larger puzzle - or so it would seem.

Oops: I just spotted a mistake which defeats the object of the example - back to the drawing board.

Edited December 31, 2013 by czardas