Commands as functions

A wrapper set of functions for commands which have an output variable.

Download

Great collection. This will definitely be useful.

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

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.

Thanks Titan, amazing work, very useful!!
I think this could be distributed with AHK?
Chris?

Chris said there will eventually be functions for all commands that return a variable but seeing how they were going to be as I didn't expect (e.g. FileExist(...) is not same as IfExist, ...) I decided to make a collection myself.

I think this could be distributed with AHK?

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'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.

functions seemingly very usable should go to include folder. being in that folder doesn't mean that they get included in every script by default (no use increasing size of compiled scripts), it just means their path isn't reqd to be given while including them in scripts.

Yes, I agree that standard functions only get included when you use something like #Include .

The time-consuming part (other than developing the functions) is organizing and documenting each new function.

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!
that'll work out by itself.. ppl posting scripts also document it by themselves.

I'm open to ideas about how the "standard includes" folder should work.

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.
Thanks Titan for the good work...

Following up on what Nemroth said, in-build functions should start with A_ like the variables,

Following up on what Nemroth said, in-build functions should start with A_ like the variables,

This would likely limit which variable names could be used in the future if implemented

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)

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.

in-build functions should start with A_ like the variables

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.

Ok, thanks to the new update, you don't need to put in the optional params - the change in script version 1.1.

Ah yes, thanks a lot for doing this.

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

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)

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.

- the size of the include file of functions (or is this irrelevant/negligible in the overall scheme of things)

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.