Commands as functions
Not currently (unless you pass the args as one big string and parse them yourself). There is a plan to have "optional parameters" in a future version, which would assign a default value to any parameter omitted by the caller.You need to put in all params ("" for optional ones you don't need), if there's a way to avoid this let me know
I think this could be distributed with AHK?
Chris?
I would like to have a standard "includes folder" in the future. However, anything that goes in there should be well-tested and documented to minimize the chance that it would change in the future. This is because changing an included function could break existing scripts as easily as changing the program itself.I think this could be distributed with AHK?
I'm open to ideas about how the "standard includes" folder should work. I'd also welcome submissions for it, but it would help me a lot if the submissions were well structured, commented, and explained. Even better would be to have a volunteer to take change of the library's organization. Such a volunteer should probably be knowledgeable enough to test and fine-tune each function.
CleanNews.in : Bite sized latest news headlines from India with zero bloat
The time-consuming part (other than developing the functions) is organizing and documenting each new function.
that's for the function developer to do... i create a function, i document! u create a function, u document! simple!The time-consuming part (other than developing the functions) is organizing and documenting each new function.
that'll work out by itself.. ppl posting scripts also document it by themselves.
CleanNews.in : Bite sized latest news headlines from India with zero bloat
May be a common initial would be a good thing. Each function witch belongs to theses "standard includes" sould begin with I_ (like include), or F_ (like function) or anything else witch is common to all these functions and allow to distinguish between them an user ones.I'm open to ideas about how the "standard includes" folder should work.
Thanks Titan for the good work...
This would likely limit which variable names could be used in the future if implementedFollowing up on what Nemroth said, in-build functions should start with A_ like the variables,
I think it's okay not to require this. After all, you can simply avoid including the file if you don't want those functions to be "known" to your script.May be a common initial would be a good thing. Each function witch belongs to theses "standard includes" sould begin with I_ (like include), or F_ (like function)
That seems a little too restrictive. However, what might be done in the future is to support a prefix such as "::" (e.g. ::WinExist) so that you're guaranteed of getting the built-in function rather than some user-defined function somewhere in the script.in-build functions should start with A_ like the variables
It seems the advantages of using these functions instead of the builtin commands would be:
- shorter scripts (can do more than one command per line, and no need to create a variable that is only going to be used once - just replace it with a function call)
- easier to read (don't have to keep asking oneself which of the params is the "output variable" etc
- easier/quicker to write scripts (for all of the reasons mentioned in the previous two points)
BUT before I go and convert all my scripts to use these functions instead of the builtin commands, and the same for all new scripts I write, I just wonder is there any impact on script performance by doing this? eg:
- the overhead of so many function calls (or is this made irrelevant in the "semi-compilation" stage)
- the size of the include file of functions (or is this irrelevant/negligible in the overall scheme of things)
- anything else?
Thanks
A function that is a wrapper for a command will of course be a little slower than running the command by itself. But unless you're calling the function thousands of times in a Loop, I don't think it would be significant.I just wonder is there any impact on script performance by doing this? eg:
- the overhead of so many function calls (or is this made irrelevant in the "semi-compilation" stage)
This will slightly increase the memory used by a script (probably by less than 100 KB). This is because each function along with its parameters and contents must be stored in memory, even if it is never called.- the size of the include file of functions (or is this irrelevant/negligible in the overall scheme of things)