Latest Beta

[JohnOne]

I see, I might as well get this question out of the way too.

Does this open up the possibility of function pointers, or is the functionality akin to that?

[Valik]

From the user's perspective, yes, this is function pointers. I'm invoking built-in and user-defined functions indirectly through a variable. Don't let the missing $ confuse you, Writer (in the first example) is a variable. The $ is now optional in the language. The following code is equally valid and functionally equivalent:

ConsoleWrite("AutoIt version: " & @AutoItVersion & @CRLF)

Local $Writer = ConsoleWrite
$Writer("What the hell, this works?" & @CRLF)

$Writer = MyConsoleWrite
$Writer("This works, too!?" & @CRLF)


Func MyConsoleWrite($sText)
    ConsoleWrite("MyConsoleWrite(): " & sText)
EndFunc

Note that MyConsoleWrite() uses mixed $ and $-less variables. While this is possible and supported it's obviously stylistically undesirable and inconsistent. You should always use $ or never use $, not mixed.

Edited April 13, 2012 by Valik

[guinness]

The $ is now optional in the language.

I was about to ask this. Thanks.

[ProgAndy]

The $ is now optional in the language.

This will break scripts if someone uses a variable called "$output" in a function called "output", right? Why don't you include the $ in the actual name of the variable, so that $var <> var? This would prevent breaking scripts and in my opinion this it would be a logical choice. Edited April 14, 2012 by ProgAndy

[JohnOne]

I would have thought that internally autoit could distinguish between a function and a type variable.

Hmmm, saying that, if a variable can be a pointer to a function, then a variable of type pointer might collide.

But then a variable of typr pointer can only be created in a DllStruct as far as I know.

I'm just confusing myself now.

[Valik]

This will break scripts if someone uses a variable called "$output" in a function called "output", right? Why don't you include the $ in the actual name of the variable, so that $var <> var? This would prevent breaking scripts and in my opinion this it would be a logical choice.

We will see how severe an impact this has. Right now my argument is you should have used better variable names including but not limited to some sort of type prefix.

I would have thought that internally autoit could distinguish between a function and a type variable.

Hmmm, saying that, if a variable can be a pointer to a function, then a variable of type pointer might collide.

But then a variable of typr pointer can only be created in a DllStruct as far as I know.

I'm just confusing myself now.

The implementation for functions as first-class objects does not involve pointers. It only provides pointer-to-function like semantics from the language side. Internally it's implemented completely differently. Do not concern yourself with implementation details. What matters is that the feature works sensibly and how people expect. Which it does, barring a bug or two. Edited April 14, 2012 by Valik

[czardas]

I think it's really interesting feature.

[funkey]

Very cool features! I always missed something like that!

But what about highlighting variables in editor? Editor can not know what it is, or am i wrong.

[Skitty]

One thing that I'd like to throw out there...

Has anyone considered making it so that the autoit syntax would be like php? I mean wouldn't it be cool if we were able to create script's in one whole damn line?

That would be a trip...

[Valik]

This will break scripts if someone uses a variable called "$output" in a function called "output", right? Why don't you include the $ in the actual name of the variable, so that $var <> var? This would prevent breaking scripts and in my opinion this it would be a logical choice.

Actually no, you are not correct. I think. Variables with $ are not ambiguous. We know they are variables so AutoIt should only look in the variable table for it. It's only ambiguous when you use $-less names in which case AutoIt has to figure out if it's a variable or a function. I actually didn't look to see how trancexx handled this situation because obviously the situation produces a name conflict.

Also as an aside, in theory $ variables will be faster (or functions will be slower) under the new system due to the ambiguity in $-less lookups requiring more work to resolve.

So yeah, making $ optional should be fully backwards compatible.

[czardas]

I'm assuming that assigning a function name to a variable will also work for array elements. That is going to be something.pretty awesome.

Maybe I worded that wong but the idea rocks.

Edited April 14, 2012 by czardas

[ProgAndy]

I'm assuming that assigning a function name to a variable will also work for array elements. That is going to be something.pretty awesome.

Wow. Two steps away from objects. I don't think it is going to happen, but let me dream

Step 1: Associative Arrays with dot-access (arrya.key)

Step 2: Something like Javascripts bind to preset parameters

Result:

Global $array[Assoc]
$array.func = Bind(objectfunc, $array)
$array.func("hello")

Func objectfunc($self, $param)
    ConsoleWrite($param & @LF)
EndFunc

Edited April 14, 2012 by ProgAndy

[czardas]

Wow. Two steps away from objects. I don't think it is going to happen, but let me dream

It seems feasable, but what do I know?

Edited April 14, 2012 by czardas

[matwachich]

Absolutly great new features!!!

For when the final release is expected?

[AdmiralAlkex]

Absolutly great new features!!!

For when the final release is expected?

When it's done.

(you should have seen that coming )

[Richard Robertson]

Func f()
EndFunc

Dim f = f

f()

Is this possible?

[Mat]

Will it be possible to pass these function pointers to *Register functions instead of strings?

Ideally we'd never have to pass function names as strings.

[AdmiralAlkex]

With the "function pointer" and array updates (seeing things unfolding on the repository before release is neato ) the next beta is going to be awesome! Great work trancexx!

[jchd]

That's opening a new range of programming styles and constructs. I wouldn't say "paradigm" but this is great.

[Valik]

Will it be possible to pass these function pointers to *Register functions instead of strings?

Ideally we'd never have to pass function names as strings.

Eventually we can modify the functions to accept the reference, yes. Right now, no, it's not implemented.