870 replies to this topic

[sumon]

Well here's another downside of removing the standard method of accessing variables: Commandline support becomes much more difficult.

Commandline support in Autohotkey

You can pass commands to a script in the format (Run) CompiledScript.exe [Switches] [Script Parameters]

It's easy to detect if there's some command input by putting this at the top of your script, example from bitlyButler:

CMDInput = %1% ; // For Commandline support, give longURL as argument (or "settings" to launch the settings, in the future)
if (CMDInput)
{
	if (CMDInput = "Settings")
		Gosub, Settings
	else
	{
		longurl = %1%
		Gosub, Shorten ; Shortens the link and displays result in traytip + clipboard
	}
}

I was about to add commandline support to more scripts, but without using standard variables (or the var = %1% way) I realized it became much more difficult, so I gave up.

As I said in the topic of Jump, I believe more - if not all - AHK scripts should have commandline support for their main function. If you remove traditional method, please add some better commandline support, by replacing %1% with for example %CommandLine_1% or something.

PS. This is not a whine. I'll add a smiley for proof. ---> :lol:

[tank]

I will post an example later
php allow variable var names

When parsing a csv that may have columns out of order I often use the header row to create a var name and then use an index to reference specific rows...

[IsNull]

1.
Like Lexikos mentioned before, there is no need of dynamic variable deref;
@a4u:

GuiControlGet, value,, % A_GuiControl
TrayTip, Edit Control, % "Name: " A_GuiControl "`nValue: " value

Most such constructs can be solved much better with Arrays. (Even better with Objects but that might be to complex for a newbie)

2.
Dynamic functions is an important feature, and I don't see any point where as AHK_L / v2 don't support that; -->

obj.Function := "mydynamicfunctionname"
obj.Function()

You even can customize this to your needs, like I've done here: Delegate Object (AHK_L)

; AHK Basic
mathop := "sub"
%mathop%(4,5)

; AHK_L
mathop := Delegate("add")
mathop.Invoke(4,5)

Add(a, b){
   return a + b  
}

Sub(a, b){
   return a - b  
}

3.

Do you have any specific ideas?

Indeed I have, but as I currently not overlooked the whole X11 stuff (actually I runned into new problems yesterday) it seems to early to make concrete suggestions. I write you as soon as I've concrete, working ideas.

I think that an array is a fairly intuitive construct. There isn't necessarily any need to expose the user to the more expansive capabilities of objects. They could use objects and not even know it.

Exactly.

[tank]

(Even better with Objects but that might be to complex for a newbie)

this is my point exactly
complex functionality shouldnt exclude newbie friendlieness

[fragman]

Wanting to automate things can also be a goal of more experienced programmers. The main strength of AHK is obviously the easy handling of hotkeys and controlling other windows. I think AHK has a very broad target group. I can only speak of myself, but I never had any problems when it comes to the concept of objects or similar structures, even at the very beginning when I started learning programming languages.

[Frankie]

many people...want to turn it into some Java / C# ...which I, honestly, can't support.

I agree that it should stay away from those stricter languages and (most of) their syntax. I think scripts should be able to do basic tasks as they do now without using objects or the more advanced topics. For example, you can write a script that spams a key to your favorite game, or click at various mouse positions every 15745 milliseconds without using anything advanced. Thats how it's now and I wouldn't expect that to change.

What is intimidating about objects though? Heres the difference with the usage most people use them for. The only change is the symbols around the variable.
Array%Item%
Array[Item]
Maybe if we could get rid of forced declaration of objects and arrays (providing #Warn UnSet... isn't set) so that the first time an object/array item is assigned a value, it just works. Possible?

[IsNull]

What is intimidating about objects though? Heres the difference with the usage most people use them for. The only change is the symbols around the variable.

Seriously?!

func(array, index){
  msgbox(array[index])
}

leads to this=>

func(array, index){
[color=red]global[/color]
  msgbox % array%index%
}

Violating the global variable space to just submit one array. Cool! I've done some bigger projects in AHK Basic and its frustrating not even to have an array. You always need to carry a couple of data properties, therefore some Array/Struct/Object is needed.

Exactly, but many people seem to forget the original idea behind AHK and want to turn it into some Java / C# / Whatever clone instead, which I, honestly, can't support.

I get that point. Additionally its not the meaning of anyone here to create a complex language. If I need something like that, I use C#.

What happens if you create some bigger project in AHK? At the beginning its damn fast, but over time it's getting more and more complicated, it becomes unmanageable, frustrating. Thats the downside of AHK Basic. Why? You are right: AHK Basic is not meant to be a programming language for big Projects.
AHK_L solved some primary problems, while keeping old ones.
My Idea is to have a language which is very simple and powerful (= AHK from Mr Chris), but can scale up to be more strict when its needed to be.

I know, the noob coder, newbie, fun coder and also our beloved game cheaters & co doesn't run into those problems, therefore they don't need it. But there are people like me who need that. More over, most of the beginners getting more experienced and what happens then?
I tell you: They leave and switch to something other. I know a couple of them.

That said, I'm not against co-existence of more newbie-friendly syntax sugars. But Commands/Dynamic Variables arn't good for newbies. They are just good for people which already know them and are comfortable with it / doesn't need more.

[guest3456]

Violating the global variable space to just submit one array. Cool! I've done some bigger projects in AHK Basic and its frustrating not even to have an array. You always need to carry a couple of data properties, therefore some Array/Struct/Object is needed.

yes this is a huge problem when making big AHK programs.

What happens if you create some bigger project in AHK? At the beginning its damn fast, but over time it's getting more and more complicated, it becomes unmanageable, frustrating. Thats the downside of AHK Basic. Why? You are right: AHK Basic is not meant to be a programming language for big Projects.
AHK_L solved some primary problems, while keeping old ones.
My Idea is to have a language which is very simple and powerful (= AHK from Mr Chris), but can scale up to be more strict when its needed to be.

this is a great vision and what i would like to see as well.


the problem i have is the difficulty understanding just how exactly objects work/are defined in AHK_L. i am a below avg coder but i have 2.5 years of compsci schooling and a little bit of self taught stuff, so i've done a little bit of oop, but objects in AHK_L are foreign to me.

the difference between array%index% and array[index] is trivial. obvioulsy no one will care about that. defining myarray := [key1, key2, key3] or whatever the proposed syntax will be fine too. but "base mechanism"? "meta functions"? these things are a big hurdle for me to get my head around. but ill keep at it..

[fragman]

You won't be needing those things for basic functionality. If some commands return an object, you would be able to access it's members like in the example mentioned above:

WinGet, object, A
Msgbox % object.Title ;Print title of active window
Msgbox % object["X"] ;Print x position of active window, different accessing syntax that allows dynamic strings for variable names

I don't think this is more difficult than calling the command with more parameters to only request a single property.

Btw, base mechanism is something related to Inheritance (go look it up if you never heard about this term). It allows you to create a "base" object that is common to other objects. Those objects will share the same keys and methods, but can be modified for different behavior. If you want to know more about general concepts, read something about object oriented programming.

[sumon]

many people...want to turn it into some Java / C# ...which I, honestly, can't support.

I agree that it should stay away from those stricter languages and (most of) their syntax. I think scripts should be able to do basic tasks as they do now without using objects or the more advanced topics. For example, you can write a script that spams a key to your favorite game, or click at various mouse positions every 15745 milliseconds without using anything advanced. Thats how it's now and I wouldn't expect that to change.

What is intimidating about objects though? Heres the difference with the usage most people use them for. The only change is the symbols around the variable.
Array%Item%
Array[Item]
Maybe if we could get rid of forced declaration of objects and arrays (providing #Warn UnSet... isn't set) so that the first time an object/array item is assigned a value, it just works. Possible?

I agree. Even when I was noobier, I used stuff like "Site_%A_Index%. On the other hand, "Site[A_Index]" would look more intuitive, or Site[1]. But the whole debate of whether AHK should only be an automation software or if we should be able to do more stuff - that's a common topic of discussion. I think AHK has the advantage of being a relatively simple programming language, and the potential of going into more advanced stuff makes it a port in to more advanced languages for people. Let's keep the simplicity for noobs though, and maybe improve it somehow.

One thing I know alot of people have problems with in the beginning is all these commas for optional parameters. Is it possible to write it differently? For example

WinGet, OutputVar , Cmd, WinTitle, WinText, ExcludeTitle, ExcludeText

; Possible to do it like this instead?
WinGet, Outputvar, Wintitle = Things to do

If so, how? If no, is an implementation possible? I bet the same goes for functions, since commands are based off functions anyway. Also, the step from command to function is unnecessarily steep (atleast it was for me). People don't understand how IfInString is exactly the same as If (InStr()) or that MyMsg("Hello world!") is just as easy to use as MsgBox, Hello world! Functions are good. What I mean is that documentation should reflect this, and maybe the way we do things - because noobs imitate those who help them.

Maybe I rambled off a bit, but if you really wanna have a discussion about where this programming language is going, my opinion is that we should discuss it from both ends - both from topend and bottomend.

[tank]

As far as large projects I dont see the problem with juduscious use of globals and a strong naming convention i have no issue with my projects over 10 k lines. still run fast and perform miracles

All I am saying is it is very convenient to have dynamic variables which are supported in robust environs and furthermore we arent trying to create an environ that enforces good habits but one thats easy to follow for the noobs.

While i wont ever understand the arguyment about commands vs functions. its 6 of one and half dozen of another.

It is a matter of convenience and code simplification to use dynamically created variables

that being said even with objects. there is a time and place for either

[infogulch]

First, I'm all for having both commands and functions.

Passing args by referencing their name is currently working for functions and there has been talk about adding that functionality for commands. I am against adding this functionality.

Commands usually have literal text fields, and referencing them by name could be too ambiguous. This is compared to functions, for which the syntax func(arg: expr) is invalid if named arg referencing did not exist and could not be interpreted any other way.

If you want to call a method with specific args by name, use function syntax not command syntax, because soon all methods will be able to be called with either.