AutoHotkey Community

It is currently May 26th, 2012, 1:43 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 42 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Commands as functions
PostPosted: May 25th, 2005, 10:01 pm 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
A wrapper set of functions for commands which have an output variable.

Download


Last edited by polyethene on September 27th, 2009, 8:40 am, edited 15 times in total.

Report this post
Top
 Profile  
Reply with quote  
PostPosted: May 25th, 2005, 10:44 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 26th, 2005, 10:41 am 
Offline

Joined: February 17th, 2005, 10:06 am
Posts: 280
Location: Hungary, Budapest
Thanks Titan, amazing work, very useful!!
I think this could be distributed with AHK?
Chris?

_________________
Is there another word for synonym?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 26th, 2005, 4:31 pm 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 27th, 2005, 2:54 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 27th, 2005, 3:50 pm 
Offline

Joined: March 28th, 2004, 3:53 pm
Posts: 1870
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.

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 1:21 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 2:07 am 
Offline

Joined: March 28th, 2004, 3:53 pm
Posts: 1870
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.

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 5:11 am 
Offline

Joined: September 7th, 2004, 9:20 pm
Posts: 275
Location: France
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...


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 10:24 am 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
Following up on what Nemroth said, in-build functions should start with A_ like the variables,


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 5:15 pm 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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 :(


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 28th, 2005, 6:30 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 2nd, 2005, 10:32 pm 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
Ok, thanks to the new update, you don't need to put in the optional params - the change in script version 1.1.


Report this post
Top
 Profile  
Reply with quote  
 Post subject: performance hit?
PostPosted: June 6th, 2005, 11:42 pm 
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


Report this post
Top
  
Reply with quote  
 Post subject: Re: performance hit?
PostPosted: June 7th, 2005, 12:30 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page 1, 2, 3  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: Klark92, Yahoo [Bot] and 16 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group