AutoHotkey Community

[Jerry]

How does it sound to have a new directive that would set the search path to find the functions? The path idea is stolen from the 'path' dos statement. I am also suggesting two variables that autohotkey maintains
1) %install_directory% <-- would be the directory path that the install program places functions that users have written and are included in the install.

2) %A_WorkingDir% <-- the working directory

Eg. #IncludePath c:\my functions;install_directory;%A_WorkingDir%

Using this scripts would not need to specify the #include statement at the top of the script. When a function is encountered, the includePath(s) would be searched to find where the function is, if it is the first time the script has encountered the function.

[Chris]

That's pretty interesting because it's more advanced, and potentially more useful, than what is typically used to implement a standard library of functions.

In many languages, you use special symbols to indicate that a #Include file is coming from a standard location. For example, if the C language style were used, you would use <>:

#include <ProcessMemory.ahk> ; For Read/WriteProcessMemory().

Your idea would avoid the need to ever do #include if a standard search path for functions is set up. Although this is convenient, it suffers from at least one major problem: performance. If there are a lot of scripts in the standard includes folder, finding the correct one and the correct function inside it might require several seconds of disk access (if the files aren't already cached). This seems an unacceptable amount of overhead to incur whenever a function definition isn't found, especially since the sheer amount of file data that must be scanned might someday be several MB. Even when the files are cached, this might be a slow and/or memory-consuming process.

Comments and contrary opinions are welcome.

[jonny]

I think the classic, standard method (<>) seems more sensible, to me at least. For one thing, I wouldn't like a few seconds of loading for basic functions that will probably become widely used, and for another, I think that way is simpler.

My two cents.

[niwi]

Hi,

the idea sounds good, but I see also a problem: code sharing. If you use a lot of function files, how do you know exactly which of them you are using? If you like to share your scripts, you have to find all the necessary files...

Using explicit #include statements should be better for the coding.

Another point:
You have a lot of files and you have two functions with the same name and maybe the same number of parameters. But your new script won't work as expected. How long does it take to find the old function?

DOS had a lot of good ideas, and if I remember, DOS 2.11 was carried out on a 320 kb floppy disk. The system doesn't knew anything about directories...

But with directories and the PATH variable the second problem appeared.

NiWi.

[Jerry]

I was thinking that the name of the function would have to match the name of the file, without the extention on it.

This would limit the search to just scanning the directory(s) for the function.

I'm not sure I would want the ability to embed a function in another script. And if I did, I would go back to using the include directive for clarity.

[niwi]

Hi Jerry,

this would be a solution. So it may be possible to use a second include statement which will search for needed function files (i.e. with suffix .ahf) in the specified directory.

On the other hand why do you need this directive? If you have a lot of functions you should know which one do you need. Can you give me an example for better understanding?

NiWi.

[Jerry]

[niwi]

[niwi]

Hi,

I've got an idea about this question:
@Chris:
Is it possible to have an additional parameter for the #include statement?

If this can be done easily, maybe it will help the whole community to use global functions, which will be provided with the AHK packet. So there can be stored some functions, divided into a few topics like
Strings.ahf
Math.ahf
Gui.ahf
and so on. All these functions should be build by Chris (not written, just put them into the files ) and will be distributed with ahk. So if someone needs a function which is not used to much so it will not be part of the autohotkey.exe, it will be stored in one of these files. And a user can load this with something like this:
#include, math.ahf, system
The parameter system indicates that the file should be loaded from the installation source, i.e. %ProgramFiles%\Autohotkey\functions.
Also a new statement like #SysInclude may be possible.

What do you think about this?

As an example for "strings.ahf":

[Chris]

This is a good approach and is probably close to what will be done. The only difference is that it seems simpler not to have a new directive or to require a new parameter, but to instead use characters that are normally illegal in a filename to flag an included file as "special":

#Include <ListMgmt.ahk>

The angle brackets in the above would signal that the file should be loaded from some standard folder rather than the script's working directory.

Also, it seems better not to have a new ".ahf" extension because in general, I think creating new extensions should be done only when there is a very large benefit. The is because new extensions increase the learning curve and the complexity of the program and its installer. In addition, a user would have to remember to associate both ahf and ahk files with their editor of choice, and configure their editor to recognize both extensions as eligible for syntax coloring, etc. Therefore, it's probably best to keep them all as ".ahk" files (but counterarguments are welcome).

[niwi]

Hi Chris,

[Chris]