Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey v2 Alpha Release


  • Please log in to reply
870 replies to this topic
a4u
  • Guests
  • Last active:
  • Joined: --

First, there are times when the user may purposely store a variable name in another variable so they can have the name handy, and use a double ref to get the variable contents.

Why may a user do that, other than because that was more or less the only tool available in AutoHotkey Basic?

Here's one specific example that comes to mind (though there's other ways to go about this):
Gui, Add, Edit, x16 y10 w130 h20 gOnKeyPress vEditControl, Some Value
Gui, Show, w167 h48, GUI
return

GuiClose:
	ExitApp
OnKeyPress:
	Gui, Submit, NoHide
	TrayTip, Edit Control, [color=red]% "Name: " A_GuiControl "`nValue: " %A_GuiControl%[/color]

If dynamic variable references were removed, there would be no simple way to loop throught the variable list.

Why would anyone need to do that?

Why do noobies try to do a lot of odd/newbie things? I was getting at that if they did just want to go through a list of numbered variables, our answer would have to be to use an object instead. This is just one area that I'm opposed to limiting what is available with AHK Basic. Personally as a noobie, I never found dynamic (double ref) variables complicated, so I see no need to remove them - but that's just my opinion. I personally don't need them now that I have more scripting experience.

I did not say anything about dynamic function calls/subroutine calls/label jumps, so ;)

Perhaps I haven't given it enough though, and perhaps it's just because I'm so used to AHK Basic syntax, but it seems odd to allow dynamic function/subroutine calls and not allow dynamic variable calls.

Anyway, I trust your judgement on this, & I don't want to postpone real development, that's just my thoughts from when I was learning AHK.

sumon
  • Moderators
  • 1317 posts
  • Last active: Dec 05 2016 10:14 PM
  • Joined: 18 May 2010
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
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
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...
Never lose.
WIN or LEARN.

a4u
  • Guests
  • Last active:
  • Joined: --
@summon - try Args[1]

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
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
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007

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

this is my point exactly
complex functionality shouldnt exclude newbie friendlieness
Never lose.
WIN or LEARN.

SomeAHKUser
  • Guests
  • Last active:
  • Joined: --

complex functionality shouldnt exclude newbie friendlieness

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.

"The Syntax is superior", etc. isn't a valid excuse to turn AHK, that is meant for complete programming / scripting beginners, that mainly want to quickly automate things, into some "higher" programming language with all kinds of complicated syntaxes.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
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
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008

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?
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

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
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

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
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
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
  • Moderators
  • 1317 posts
  • Last active: Dec 05 2016 10:14 PM
  • Joined: 18 May 2010

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
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
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
Never lose.
WIN or LEARN.

infogulch
  • Moderators
  • 717 posts
  • Last active: Jul 31 2014 08:27 PM
  • Joined: 27 Mar 2008
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.