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
fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009

...if I do understand your example, you mean it would be interpreting it like...

if (i=1 msgbox) msgbox, wow

Yes. Sorry, that wasn't very clear at all.

...but as you can see, if that is what I meant, I would move the parens around like this. If if's were changed to require an "outer level of parens", around the entire expression (like JS), I think that would cure the problem you are describing...or even a directive: #IfsRequireParens

One of the things I like about AutoHotkey is it's not as strict as other languages. I like the freedom to write If (A>5) and (B<3) because it's clearer to me. Some might disagree.

This is good when no ambiguity is possible. However, once it could have different possible meanings, a strict version should be preferred.

I would also support dropping commands, because it might be unclear which params are variables and which are text without looking at the docs.

sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008

If they're not valuable enough to be built-in functions I would question their value as operators, which to me is far more complex to understand.

My meaning was that they are of less value as functions because they are less readable.


In that respect I can see where an operator makes sense.

I worry that the function names, even as abbreviated as they are, just stretch the code out to the point of nuisance. Possibly a compromise?

That's rediculous. I won't stop you from defining your own L() and U(), but I won't make them built-in.


I'm not saying my idea is the answer, but I'm not sure the proposed answer necessarily speaks to AHK's goal of simplicity, either.

I've wondered for a while why we have commands like WinSet and WinGet with numerous sub-commands, then separate commands like WinGetClass and WinSetTitle. I think that making these consistent would be an improvement, whether that means a couple commands with many sub-commands, many individual commands, or both (e.g. have WinGetTitle, var and WinGet, var, Title).

I plan to change StringSplit and RegExMatch to output an array (an object) instead of a pseudo-array (a bunch of variables). RegExMatch could potentially provide both the position and value of each capturing sub-pattern.


Would it be possible for RegExMatch to also return the number of occurrences like InStr()? I'd imagine speed may be adversely affected, but it doesn't hurt to ask.

Would there be similar plans to have WinGet output an array when using the List/ControlList/ControlListHwnd options (kind of like what I was shooting for in my command object function library)?

Also, would it be possible to make WinGet a function so you could grab particular output without passing to var? Obviously we could do it ourselves but it would be a nice addition:

MsgBox %   WinGet("ahk_class Notepad").Title

On the above note, would it be possible to create a Str() function that is capable of outputting all (or many) of its current capabilities? Example:

var :=   "Hello World!"
MsgBox %   Str(var).Upper   ; HELLO WORLD!
MsgBox %   Str(var).Sub(-5)   ; WORLD!
MsgBox %   Str(var).In("Hello")   ; true
MsgBox %   Str("I Just wanted to say hello world!").In(var,True)   ; false


dysmas
  • Members
  • 63 posts
  • Last active: Apr 06 2011 11:01 AM
  • Joined: 28 Dec 2010
Hello, in the plan about AutoHotkey V2, I read :

The following directives seem to complicate the code and documentation more than they're worth
#Delimiter

Jonny said: As for eliminating those and #EscapeChar and #CommentFlag, I'll say that I use them myself to change the escape to \ and the comment to // ... Here's my verdict then: Eliminate #DerefChar and #Delimiter, since most people have probably never heard of them anyway, but keep #CommentFlag and #EscapeChar if only to have the options there.


Sorry but for #Delimiter you are wrong. There are guys who use it, I am one of them. For Unichars (http://unichars.sourceforge.net) it is mandatory otherwise the character | cannot be used in codes. I replaced the delimiter by chr(1)
Please, don't remove this directive. I would be very interested in passing unichars in AutoHotkey v2

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

I would also support dropping commands, because it might be unclear which params are variables and which are text without looking at the docs.

Indeed. Parameters should always be expressions, in consequence just Functions should remain. This would also shorten script code.

If shortening:
if (i=1) 
   msgbox("wow")

Or, like mentined before, one Line statement should be possible with brackets:
if (i=1) { msgbox("wow") }


  • Guests
  • Last active:
  • Joined: --

Visual Basic is not a language to model after, JavaScript is.

How so?

...I just don't like the Syntax of VB. It does everything weird/wrong. I have used QBasic, long ago & that was fun then. But once I saw/used the Syntax of JavaScript, I fell in love, so to speak. JavaScript just does almost everything right...
[*:3ej3f0ha]you DON'T need to declare vars (like in C {& probably VB})
[*:3ej3f0ha]vars can hold a string or a number or anything else (& change between those at runtime) without hassle (try that in C {or VB})
[*:3ej3f0ha]if's have sensible syntax (none of that "if i=1 THEN"...I hate the "then" on if's in VB/Basic-like languages)
[*:3ej3f0ha]you DON'T need to put a damn semi-colon at then end of each line (like in C {soo annoying}), but you can add one, if you want more statements on one line!...I know more annoyances about C, since I actually wrote a few "programs" in it, I've never actually "used" VB, I just saw the syntax & ran away. I do know it (VB) has the WORST concat char ever: "&"...when I saw code using that...

imagine_this_is_vb="testing" & 123 & "weird"
...I'm like "bitwise-and a string & number & another string?".

and is much more widely used as a PC-scripting tool.

..."widely used", doesn't always mean "good". Internet Explorer is "widely used", only because it: 1) is/was installed by default...2) people don't understand what a "browser" is, they just click that blue E on the desktop when they want "online". Didn't mean to get off on a browser tangent, but what I mean is "widely used" is a bad indicator. Something could be widely used cuz the marketing pushes it so hard. Like all of Microsoft's crap.

and I was referred to AHK when I heard it was "Simpler, more intuitive, and more powerful than VBScript"

...whoever told you that, is right!...AHK is waayy better than any VB (or Basic-like) language.

maul.esel
  • Members
  • 790 posts
  • Last active: Jan 05 2013 09:26 PM
  • Joined: 28 Feb 2011

I would also support dropping commands, because it might be unclear which params are variables and which are text without looking at the docs.

:shock::shock: No, don't do that :!::shock::shock:
I think AHK would lose lots of its simplicity :( :!:
To me, commands made learning AHK A LOT easier!

I was already shocked when I thought IronAHK would only support functions,
but then I was so happy when I saw it would support commands, too.

I understand it's a bit unclear about the params, but
1) AHK has a wonderful documentation (which should be updated with v2 :!: )
2) personally, I think of the current way as easily understandable
3) and thus I wouldn't change a lot of this syntax in v2.

Once again about expression assignment:
1) I think keeping := as expressional operator would be good as it is consistent with .=, -=, +=, |=, ...
2) As I stated above, I'm not sure about removing the traditional operator. Many people use it, but it also causes confusion.
But please don't introduce a new command like Assign. (I already think of EnvSet as unnecessary.)

Would it be possible for RegExMatch to also return the number of occurrences like InStr()?

Isn't there a 2nd algorithm in the pcre - library which searches for multiple results? If this could be implemented, this would be great :D

About this:
if (i=1) { msgbox("wow") }
Wouldn't this affect the new json syntax?


Regards
maul.esel
Join the discussion on The future of AutoHotkey
Posted Image Visit me on github Posted Image
Win7 HP SP1 64bit | AHK_L U 64bit

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

I think AHK would lose lots of its simplicity
To me, commands made learning AHK A LOT easier!

I heavily disagree.

2) As I stated above, I'm not sure about removing the traditional operator. Many people use it, but it also causes confusion.


First off, keeping Commad-like Syntax is bound to also keeping the "traditional" Variable dereferecing %var%.

1. Commands create unnecessary and confusing alternatives when variables coming into play.

2. Commands need traditional vars -> whats IMHO also bad.

3. Commands have not that intuitive syntax-> it's not that clear when using vars and when not. This also makes reading Code harder.

For a AHK v2 -> what actually means cleanup old stuff and break compatibility, removing those command/traditional vars is one of the primary points for me ;)

Wouldn't this affect the new json syntax?

No. "If" is a reserved keyword...

maul.esel
  • Members
  • 790 posts
  • Last active: Jan 05 2013 09:26 PM
  • Joined: 28 Feb 2011
So we're not of the same opinion ;-)

About the "traditional operator": I'm not sure if you understood me right, I was talking of
var = literal text

If is a reversed Keyword...

:?: Can you explain that? I don't see what this has to do with json syntax?
(I don't even know what a reversed (reserved?) keyword is :lol:)

Regards
maul.esel
Join the discussion on The future of AutoHotkey
Posted Image Visit me on github Posted Image
Win7 HP SP1 64bit | AHK_L U 64bit

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
IsNull++
Never lose.
WIN or LEARN.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
There's something which I want to be removed: dynamic variable references (MyArr%Counter%). There's no longer any need for them as we have objects/arrays.
This wouldn't be valid code anymore:
foo := "Hello world"
bar := "foo"
MsgBox % %bar%


infogulch
  • Moderators
  • 717 posts
  • Last active: Jul 31 2014 08:27 PM
  • Joined: 27 Mar 2008
Personally I like function syntax much better and will use it everywhere possible. (which will just be "everywhere" eventually)

I also agree with IsNull's point that command syntax is sometimes very confusing. Sometimes it's plain text, sometimes an expression is supported, sometimes it HAS to be a single variable because it's an output param, "if I use %var% in this param will it use the contents of var or try to double-dereference it?" etc... the manual must be consulted constantly, whereas functions don't have any of these specific problems.

HOWEVER, this is only my opinion, and command vs function syntax is a very personal coding style choice and should be left as such. I thought Lexikos made it clear that he would definitely support both function or command syntax for all methods, so I wonder why this is even being discussed.

IsNull: you're working closely with IronAhk and iirc poly has also expressed that he would fully support both function and command syntax for all methods as well, so I'm curious why you're arguing for this.

Anyway, another topic:
Lexikos: We have a bit of a problem with commands that have multiple output args/vars. How to return them with a single return value when they are converted to functions?

How about this: in v2, for any methods that have multiple outputs in v1, return an Object with the v1 param names as the keys.

For v2 you could also remove any multi-output vars for the command syntax and change it to *one* output var that contains an object just like the function syntax suggested above.
;v1
WinGetPos, X, Y, Width, Height, My Window
msgbox %X%, %Y%, %Width%, %Height%

;v2 function syntax
out := WinGetPos("My Window")
msgbox(out["X"] ", " out["Y"] ", " out["Width"] ", " out["Height"])

;v2 command syntax
WinGetPos, out, My Window
msgbox %out["X"], %out["Y"], %out["Width"], %out["Height"]   ;of course this syntax still needs ironing out


There's something which I want to be removed: dynamic variable references

Hmmm, I think I like this idea, maybe.

sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008

Lexikos: We have a bit of a problem with commands that have multiple output args/vars. How to return them with a single return value when they are converted to functions?

How about this: in v2, for any methods that have multiple outputs in v1, return an Object with the v1 param names as the keys.

For v2 you could also remove any multi-output vars for the command syntax and change it to *one* output var that contains an object just like the function syntax suggested above.


You mean like this?

a4u
  • Guests
  • Last active:
  • Joined: --

There's something which I want to be removed: dynamic variable references (MyArr%Counter%). There's no longer any need for them as we have objects/arrays.
This wouldn't be valid code anymore:

foo := "Hello world"
bar := "foo"
MsgBox % %bar%

Personally, I disagree with this on 2 levels. 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. Secondly, even though I discourage the use of Pseudo-Arrays over Real Arrays, for a noobie, a simple variable list like item1, item2, item3 isn't necessarily bad coding. If dynamic variable references were removed, there would be no simple way to loop throught the variable list. Sure the user could just learn how to use objects, but why force them to?

I think AHK would lose lots of its simplicity
To me, commands made learning AHK A LOT easier!

I heavily disagree.

I strongly disagree with you on this one IsNull. NOW I think Commands may cause users to be confused when they first start using functions - however - as a noobie not coming from any other language, I thought Commands were extremely easy to learn & use. In fact, that was one of the primary reasons I chose AHK over AutoIt.

Disagree
  • Guests
  • Last active:
  • Joined: --

There's something which I want to be removed: dynamic variable references

I don't understand, why that should be removed - it doesn't make the script slower and, since it's a feature that beginners don't need, doesn't add much confusion, since, when your using it, you already have a basic knowledge of AHK and scripting in general and know when to use it, etc.

Forcing an user to always use an object for everything isn't that user-friendly, imho.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
It does create major confusion (at least in v1):
foo := Hello ; foo is blank
bar := %foo% World ; "why ain't this deref working?"

Forcing an user to always use an object for everything isn't that user-friendly, imho.

What "everything"? Can you post an example that is much simpler with var references instead of objects?