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

[Morthawt]

Am I right in assuming this is purely a time saving thing? Or is there some other aspect to this I am missing?

[trancexx]

Functions became first class objects some time ago so you can do this:

$Variable = Beep
$Variable()

Is that what you are asking about?

[Morthawt]

Yes. The only real thing I could come up with is instead of always using ThisNewFunctionThatHasAReallyDescriptiveName(whatever) you could

$go = ThisNewFunctionThatHasAReallyDescriptiveName

$go(whatever)

I am just trying to get a full understanding of these few new features so that I know where I am going with them and why. So is this purely a time saving thing or is there some important nuance I am missing of another reason this is good?

Edited December 29, 2013 by Morthawt

[JohnOne]

There has been lengthy discussions about the pros and cons of this ability when they were introduced into beta.

I don't remember a link in dev chat, but worth having a peek, see if you can find it.

[trancexx]

I don't believe there has ever been any "cons". Unless there was somebody really retarded involved in discussion.
Besides $Variable() existed since almost forever in the language. It was normally used for object variables to access default property/method:

$Variable = ObjCreate("Shell.Explorer")
ConsoleWrite($Variable() & @CRLF)

[JohnOne]

I don't believe there has ever been any "cons". Unless there was somebody really retarded involved in discussion.

 

Just an assumption darlin, someone always pipes up with a negative.

[Morthawt]

Thanks. I will have a look around.

[DatMCEyeBall]

Just an assumption darlin, someone always pipes up with a negative.

[Morthawt]

I give up, I cannot find anything on it.

[Unc3nZureD]

Anyways it can be used to make some more difficult obfuscation methods

[JohnOne]

You can also pass a function to another function with great ease.

[jchd]

and it rules out Call() (unless one is willing to make horrible computed function calls).

[guinness]

Morthawt.,

 A good example is _ArrayDisplay() where before the user function was being called by Call(), but I made a suggestion (in the MVP Forum) to change to a "first class object". Voila, you now see a real world example.

JohnOne,

I don't even remember a discussion taking place about this.

[JohnOne]

I've got a lousy memory, but some things just stick in my head, one of the first beta's released post 3.8.1 I think.

[guinness]

Well it was first introduced here >> '?do=embed' frameborder='0' data-embedContent>> and discussed a little bit >here. But it's a good addition to the language and no one should doubt that!

[JohnOne]

I'm probably remembering just reading about it from various threads.

>Here's where I first seen it pop up.

[Morthawt]

Morthawt.,

 A good example is _ArrayDisplay() where before the user function was being called by Call(), but I made a suggestion (in the MVP Forum) to change to a "first class object". Voila, you now see a real world example.

JohnOne,

I don't even remember a discussion taking place about this.

 

In the example code for _ArrayDisplay() I see no mention of using Call() I don't think I understand what you are getting at. I still do not understand the benefit of this first class object business with regards to this new function thing. What is the tangible benefit to using it? I am just trying to understand it so that I know when and why to use it.

Edited December 30, 2013 by Morthawt

[Melba23]

Morthawt,

Here is a concrete example, albeit simple, of how the new fucntionality works.

Up until now, passing a function to another function had to be done like this:

; Determine Autoit folder
Global $sRootFolder = StringLeft(@AutoItExe, StringInStr(@AutoItExe, "\", Default, -1))
ConsoleWrite($sRootFolder & @CRLF)

; Define a function
Func _FunctionToCall($sFile)
    ConsoleWrite($sFile & @LF)
EndFunc   ;==>_FunctionToCall

; Pass the function NAME to another function
_ListFolder($sRootFolder, "_FunctionToCall")

Func _ListFolder($sPath, $sFunctionToCall)

    If StringRight($sPath, 1) <> '\' Then $sPath &= '\'
    Local $hFind = FileFindFirstFile($sPath & "*.*")
    If $hFind < 0 Then Return SetError(1)
    Local $sFile
    While 1
        $sFile = FileFindNextFile($hFind)
        If @error Then ExitLoop

        ; We need to use Call to run the function as all we have is the NAME
        Call($sFunctionToCall, $sFile) ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

    WEnd

    FileClose($hFind)
EndFunc   ;==>_ListFolder

For various reasons this was less than ideal - particularly if you used Obfuscator.

We can now do it like this:

; Determine Autoit folder
Global $sRootFolder = StringLeft(@AutoItExe, StringInStr(@AutoItExe, "\", Default, -1))
ConsoleWrite($sRootFolder & @CRLF)

; Define a function
Func _FunctionToCall($sFile)
    ConsoleWrite($sFile & @LF)
EndFunc   ;==>_FunctionToCall

; Pass the function itself to another function
_ListFolder($sRootFolder, _FunctionToCall)

; The function is assigned to a variable in this function definition line 
Func _ListFolder($sPath, $hFunctionToCall)
    
    If StringRight($sPath, 1) <> '\' Then $sPath &= '\'
    Local $hFind = FileFindFirstFile($sPath & "*.*")
    If $hFind < 0 Then Return SetError(1)
    Local $sFile
    While 1
        $sFile = FileFindNextFile($hFind)
        If @error Then ExitLoop
        
        ; We can now run the function directly
        $hFunctionToCall($sFile) ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        
    WEnd
    FileClose($hFind)
    
EndFunc   ;==>_ListFolder

Does that help?

M23

[martin]

@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.

[Morthawt]

Yes I think so, unless I am mistaken you cannot use Call() in scripts you obfuscate because calls are needed during de-obfuscation right? So this offers a way to not break the script by enhancing it's ability to function in other environments. Are there any other environments where this would be crucial?

So far I have:

• 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.
• Can be used inside a function in a way that the original function, when called, can have a function as part of it's parameters so the function will perform different actions based on the "next" function that was added as a parameter to the original function as in your example. EDIT: Although as the poster above has said, that will only work if the same number and context of parameters are the same, else you might be passing a file path as a message box type etc.

Edited December 30, 2013 by Morthawt