DoFile

[Manadar]

Dynamically execute code inside a file. Where as #include is static at compile time. DoFile is dynamic at run time. This allows for very simple plugin architecture in AutoIt.

$search = FileFindFirstFile("plugins\*.*")  

While 1
    $file = FileFindNextFile($search) 
    If @error Then ExitLoop
    
    DoFile($file)
WEnd

[Valik]

I'm not sure this is the right approach. I think a better approach would be to allow a3x files to have an export table, provide some native functions for reading this export table and provide ways for scripts to call into a3x files and access the exported functions. In other words, a3x files should emulate DLLs.

I think there are a number of issues with your suggestion. I assume the intent is that $file can see the global variables of the caller and that the caller can see functions or global variables from $file, otherwise you would just use Run(). I think that this introduces a lot of complexities that would be easier to manage with the previously mentioned idea that a3x files behave more like DLLs.

[Manadar]

A plugin is loaded by the main application and then the plugin can consume services from the main application according to a some specific interface. How would a3x files consume these services? How do you compile an a3x when you call functions that are not yet available? Heavy usage of Call maybe, or maybe we need to rely on COM server or dll callbacks (somehow) which are both not optimal.

The ability to use a3x files as dll files is very powerful, but maybe it should be considered separately instead of DoFile vs a3x dll. Modifying scripts source code (by another script) together with DoFile poses no limitations: Full AutoIt reflection libraries are possible.

[Manadar]

What sort of complexities were you thinking about, Valik? In the sense of duplicate functions and variable names or AutoIt internal technical difficulties?

[Valik]

Replying to Manadar:

What sort of complexities were you thinking about, Valik? In the sense of duplicate functions and variable names or AutoIt internal technical difficulties?

Duplicate variables would just manifest as subtle bugs unless they were Const. Duplicate functions are a syntax error. I think that AutoIt would need to implement file-based scoping for this situation. You can't silently ignore either the caller or callee duplicate function because the signature may be different. You would need for code that comes from the callee to use the function found inside the callee and code from the caller would need to use the caller code. Now, if functions have file scope then variables should as well. But if that is the case, how does the callee tell the caller what variables/functions it can use that will actually call into the callee? This would likely entail a new Export keyword (Applicable to functions or variables). Or it would require some other functionality like pseudo-object syntax where DoFile() returns a "handle" which can be used thusly:

Local $hScript = DoFile("Script.au3")
ConsoleWrite($hScript.g_sVar)

Script.au3:

Global $g_sVar = "Test"

Or maybe functions to access things in the callee:

Local $hScript = DoFile("Script.au3")
ConsoleWrite(DoFileReadVar($hScript, "g_sVar"))

I'm sure there are other issues that are not quite so obvious.

Or, it could just be a simple, crude implementation that sucks and doesn't offer anything over /AutoIt3ExecuteScript. /shrug

[Manadar]

Lua uses file based scoping as well. When you define a variable with the local keyword it goes onto the file scope, if you declare it with global keyword it goes onto the global scope and can be accessed anywhere. This allows you to define private/public members with local/global.

I've made an example on how we can already do much of what you described: ​http://www.autoitscript.com/forum/topic/129491-autoit-plugin-architecture/ the only difference is that this uses COM to share variables.

In AutoIt, I think that an Export keyword is probably the best approach. Because it's not a bitch in backwards compatibility, which changes to local/global would be. Just remember that the main script also needs to be able to Export functions so that the plugins can use them.