| View previous topic :: View next topic |
| Author |
Message |
Titan
Joined: 11 Aug 2004
Posts: 5026
Location: imaginationland
|
 Posted: Wed May 25, 2005 10:01 pm Post subject: Commands as functions |
 |
|
A wrapper set of functions for commands which have an output variable.
Download with instructions
Last edited by Titan on Tue Jan 01, 2008 12:05 pm; edited 14 times in total |
|
| Back to top |
|
 |
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Wed May 25, 2005 10:44 pm Post subject: Re: Commands Function Collection |
|
|
Great collection. This will definitely be useful.
| Titan wrote: | 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. |
|
| Back to top |
|
|
SanskritFritz
Joined: 17 Feb 2005
Posts: 283
Location: Hungary, Budapest
|
| Posted: Thu May 26, 2005 10:41 am Post subject: |
|
|
Thanks Titan, amazing work, very useful!!
I think this could be distributed with AHK?
Chris?
_________________
Is there another word for synonym? |
|
| Back to top |
|
|
Titan
Joined: 11 Aug 2004
Posts: 5026
Location: imaginationland
|
| Posted: Thu May 26, 2005 4:31 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Fri May 27, 2005 2:54 pm Post subject: |
|
|
| SanskritFritz wrote: | | 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. |
|
| Back to top |
|
|
Rajat
Joined: 28 Mar 2004
Posts: 1717
|
| Posted: Fri May 27, 2005 3:50 pm Post subject: |
|
|
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.
_________________
 |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Sat May 28, 2005 1:21 am Post subject: |
|
|
Yes, I agree that standard functions only get included when you use something like #Include <ListMgmt.ahk>.
The time-consuming part (other than developing the functions) is organizing and documenting each new function. |
|
| Back to top |
|
|
Rajat
Joined: 28 Mar 2004
Posts: 1717
|
| Posted: Sat May 28, 2005 2:07 am Post subject: |
|
|
| Chris wrote: | | 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.
_________________
|
|
| Back to top |
|
|
Nemroth
Joined: 07 Sep 2004
Posts: 262
Location: France
|
| Posted: Sat May 28, 2005 5:11 am Post subject: |
|
|
| Chris wrote: | | 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... |
|
| Back to top |
|
|
Titan
Joined: 11 Aug 2004
Posts: 5026
Location: imaginationland
|
| Posted: Sat May 28, 2005 10:24 am Post subject: |
|
|
| Following up on what Nemroth said, in-build functions should start with A_ like the variables, |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Sat May 28, 2005 5:15 pm Post subject: |
|
|
| Titan wrote: | | 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  |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Sat May 28, 2005 6:30 pm Post subject: |
|
|
| Nemroth wrote: | | 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.
| Titan wrote: | | 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. |
|
| Back to top |
|
|
Titan
Joined: 11 Aug 2004
Posts: 5026
Location: imaginationland
|
| Posted: Thu Jun 02, 2005 10:32 pm Post subject: |
|
|
| Ok, thanks to the new update, you don't need to put in the optional params - the change in script version 1.1. |
|
| Back to top |
|
|
Guest
|
| Posted: Mon Jun 06, 2005 11:42 pm Post subject: performance hit? |
|
|
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 |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Tue Jun 07, 2005 12:30 am Post subject: Re: performance hit? |
|
|
| Quote: | 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.
| Quote: | | - 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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
