So with no recursion it is 4 look ups at worst with average 2 probably. Lets forget about recursion then.
Maybe the userlib should search recursively, but not the stdlib. This would boost performance a little.
You can create index.dat on installation, and check if Include dir is changed on startup (using modification date). If it is, you can rebuild index.dat if it is not (and in 99.9% of cases it will not be changed) u can use index.dat instead using File System functions. Using this file will make recursive search instant, and any other search.
This seems complicated, so maybe it should be deferred until after the initial release (and implemented only if it significantly boosts performance).
I think that you maybe have a point with double underscore. We can make a rule that double _ is class separator and that it will be included as described above without looking for entire construct as file name.
After reconsidering, I think double-underscore might be bad because it's sometimes hard to visually distinguish between a double and a single underscore. Also, it would lead to the undesirable restriction that function names can never legitimately contain double underscores (unless they're classes).
Using a "#" or "@" for modul/class functions would remove the requirement to not name a new lib function SSFName_Function. But it would just add a new requirement just with the new symbols. But I like the "@" since it reflects the dependency to a modul/class.
@ is definitely used to much lesser extent then _ in function names.
Its funny though... it looks like module is part of the function ( MMenu AT Create, contrary to real situation - Create AT MMenu)
It was tentatively planned for v2 to restrict function/variable names to alphanumeric and underscore. Also, I don't think either @ or # is that friendly or readable, so maybe it's best to stick with a single underscore and search for a class name only when all other searches fail; that is, right before the program displays "Call to nonexistent function".
it would be good to reserve _ in stdlib only for classes. This is small rule and will create nicer environment. If you see _ in the name, you know it is part of some module, so you can check out the module to see what other things it offers. If you don't see _ you know it is SSF.
This might not be optimal because some functions don't read very well with InitCaps and thus underscores are preferable. For example, "LVAdd" is visually hard to see as two words, but "LV_Add" is better.
INIT function must be used for modules requiering action in autorun section
One way to do this is with static variables when they someday support function-calls as initializers; e.g. static s := random_seed_init()
. Such functions would be auto-called only once, prior to the start of the auto-execute section.
Until then, a function or class can have logic that initializes itself by detecting whether a global variable is blank. If it's blank, each public function (at least ones that are ever likely to be called first
) would run some extra code. For example:
if not RandomIsInitialized
#Lib U "%A_AHKPATH%\Include-User" S "%USERPROFILE%\My Documents\AHKStdLib"
I'm leaning toward the following:
#lib ; No libraries, so no searching.
#lib path1 > path2 [> path3...] ; explicitly named directories.
#lib ?path1 ; Use leading question mark to enable recursive search in that folder.
#lib ?*user > *std ; This is the default so would never need to be specified.
#lib *std > ?*user ; reverse the default order: search std before user.
#lib *std ; stdlib only
I'm also leaning toward "My Documents\AutoHotkey UserLib" as the default userlib because the only practical alternative is to have no
userlib by default (in which case it would be enabled only via registry, environment variable, or directive). Of course, "My Documents\AutoHotkey UserLib" wouldn't be created automatically. If it doesn't exist (and it usually won't for casual users), no userlib searching is done.