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
IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

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.

Poly defined that IA v1 will be 1:1 compatible to AHK Basic. So it will be.

While 1:1 Compatibility is not that important for me, it's the primary goal of Poly, and I respect that. Further, there isn't that much overhead to support that. IA translates the AHK script code first to fit some new definitions, Commands are then replaced with function calls for example.

While you're right, it is a matter of coding style, I had a key experience:
Two years ago, I teached AHK (Basic) at school (non informatic class) some interested folks in a compulsory optional subject (IT).
For Beginner, it was kind of hard to finally understand how expressions work and after that they run into the need (coz they wanted to use some commands) to master also the traditional handling of variables.

Experienced user prefer Function Methods, and since then I'm sure that also Newbies avail when there is just one, non limited way.

Most AHK Newbies, where are not teached by an experienced AHK user take the other way -> they master the Commands/Traditional way of Variable handling and then they run into a blind alley, as the need to evaluate expressions will come up. All what they learned is with one hit no more valid, and thats frustrating.

Objects:
While I absolutly prefer OOP Style I agree that this is truly no what a beginner likes.
But: I'm quite not sure if it's bad to let newbies just use objects. Accessing Properties/Methods seems to be very intuitive and handy, even for Newbies.

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

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.

I like this idea a lot :!:
Although this is not IronAHK, once again :lol: : I think IA particularly uses that (also WinGet*?).

This would also be consistent with my idea above
of giving an object instead of a lot of parameters.
But on the other hand, objects might be kind of "frightening" for new users.

About the dynamic variables: I wouldn't like them to be removed.
There are also cases in which they are necessary, e.g. %var% := value

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

peterm
  • Members
  • 60 posts
  • Last active: Jul 04 2013 05:24 PM
  • Joined: 25 Jul 2006
As an old timer used to older languages I would like to see the end of %var%, I still haven't got my head round when they are in or out.
I now need to learn the OOP basics and this is a good forum/language to do that.
Peterm

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

There are also cases in which they are necessary, e.g. %var% := value

Why? You gave me a very vague example. If it's about settings, you can easily do this:
settings := {}

; These functions are not even necessary.
;
SetSetting(setting, value)
{
    global settings
    settings[setting] := value
}

GetSetting(setting)
{
    global settings
    return settings[setting]
}


maul.esel
  • Members
  • 790 posts
  • Last active: Jan 05 2013 09:26 PM
  • Joined: 28 Feb 2011
Ok, there might be other ways as you suggested.
But once again: I don't think dynamic referencing "hurts" anybody, so why remove it? There are more important changes :)

Edit: and one more thing: if literal assignments are kept, I think @= would be better than `= (as fincs suggested)
Join the discussion on The future of AutoHotkey
Posted Image Visit me on github Posted Image
Win7 HP SP1 64bit | AHK_L U 64bit

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008

There's something which I want to be removed: dynamic variable references (MyArr%Counter%)...

Theres two sides. I use them from time to time in scripts because they make it easier to program. When they are needed, the only work around is a looooong if-else branch (In C++ usually a switch statement). On the other side, they never make code clearer and confuse new users. To be fair though, I couldn't think of an example off the top of my head.

The only current work around I can think of is holding all your variables in one object (messy)
; Past
Some_var := "abc"
%some_var% := "Hello World"
Msgbox %abc%

; Future
V := Object()
V["Some_Var"] := "abc"
V[ V["Some_Var"] ] := "Hello World"
Msgbox % V["abc"]

aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
As long as it's still possible to define object methods using dynamically created strings dynamic references aren't really needed I think. However, I don't think there are any good reasons for removing them either, so I vote for keeping them.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

When they are needed, the only work around is a looooong if-else branch (In C++ usually a switch statement).

Once again, I want a real world example. I've never had this situation happen AFAIR.

The only current work around I can think of is holding all your variables in one object (messy)

1) Why do you need access to every single variable?
2) An object is still less messy that polluting the global scope. Just see how it can turn out horribly wrong...

SomeImportantVar := "a value"

; Imagine these are read from a file...
KeyToSet = SomeImportantVar
ValToSet = Malicious value...

SetSomething(KeyToSet, ValToSet)

SetSomething(var, value)
{
    global
    %var% := value
}

Oh, and your AHK_L code can be nicely rewritten as this:
V := {}
V.Some_Var := "abc"
V[V.Some_Var] := "Hello World"
MsgBox % V.abc


nimda
  • Members
  • 4368 posts
  • Last active: Aug 09 2015 02:36 AM
  • Joined: 26 Dec 2010

[*:6lxhvpko]you DON'T need to declare vars (like in C {& probably VB})
[*:6lxhvpko]vars can hold a string or a number or anything else (& change between those at runtime) without hassle (try that in C {or VB})
[*:6lxhvpko]if's have sensible syntax (none of that "if i=1 THEN"...I hate the "then" on if's in VB/Basic-like languages)
[*:6lxhvpko]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!

[*:6lxhvpko]In VBScript, you ONLY need to declare vars if you have "Option Explicit" turned on, which is a feature many have asked for for AHK(as in an option to prevent typos, not default, just as in VBS.)[*:6lxhvpko]Same with VBScript. Its called type "variant."[*:6lxhvpko]Okay, suit yourself without "then"s, I have nothing against not liking 'then'
[*:6lxhvpko]Umm... You don't need anything but a return at the end of each VBScript line...and if you want multiple statements you can use : operator.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008

Just see how it can turn out horribly wrong...

I see your point. I'd say get rid of derefs in variables as long as derefs in functions' names can be kept.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
I did not say anything about dynamic function calls/subroutine calls/label jumps, so ;)

which is a feature many have asked for for AHK(as in an option to prevent typos, not default, just as in VBS.)

Already possible:
#NoEnv
#Warn UseUnsetLocal
#Warn UseUnsetGlobal

MsgBox % SomeUninitializedVar ; triggers warning
Func()

Func()
{
    MsgBox % AnotherUninitializedVar ; triggers warning
}


JoeSchmoe
  • Members
  • 304 posts
  • Last active: Feb 28 2013 05:39 PM
  • Joined: 17 Feb 2008

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.

+1

I think that there is a big gap between what new programmers think is simple and what more experienced programmers think is simple. We can come up with all sorts of weird examples where commands and pseudo arrays make things more complicated, but simple coding structures like commands and double derefs will help get people to the point where they actually face some of those weird examples. Of course, at that point, they can easily switch from commands and pseudo arrays to functions and objects. The transition would be quite simple. However, if we force them to use objects and functions from the start, they may never get that far.

In the end, it's Lexikos' decision to make. I support the more flexible approach he's taking, and would even like the idea of keeping the documentation for objects slightly hidden away as it is now in the documentation. Why? There's a moment when a newbie looks at the documentation and tries to get a sense of whether or not he or she is capable of learning the language, given the amount of time he or she is willing to put in. "Objects" sounds completely foreign and scary. (I figure it probably won't stay like this, but, hey, I'll still appreciate it the way it is now for as long as it stays this way.)

comvox
  • Members
  • 143 posts
  • Last active: Jan 29 2017 06:53 AM
  • Joined: 20 May 2009

I think that there is a big gap between what new programmers think is simple and what more experienced programmers think is simple. ...
In the end, it's Lexikos' decision to make. I support the more flexible approach he's taking, and would even like the idea of keeping the documentation for objects slightly hidden away as it is now in the documentation. ... "Objects" sounds completely foreign and scary. (I figure it probably won't stay like this, but, hey, I'll still appreciate it the way it is now for as long as it stays this way.)


Thank you, JoeSchmoe!!!!

If I am looking at the proper documentation, the present documentation for objects in autohotkey_l is probably very good -- if you already know what object-oriented programming is all about, if you just need to learn the details for how ahk_l itself implements objects because you already know what to do with them and why. I don't. And I don't really want to spend a lot of time on this. So my questions are:

* is there a relatively modest-length discussion somewhere which gives one the basic orientation one needs to use objects in autohotkey_l? Gives really basic examples and describes simply why one cares about it, and which scripts would benefit from it? And, although this is probably an unrealizable utopia, would make it so I could at least understand someone else's programs which do use them (which would let me modify them for my use)?

* who has to be concerned with COM? I looked it up in the wikipedia, and I am utterly confused. Is it only of use for people who use Microsoft Office or do fancy programming with Windows internals? What about users of WordPerfect? KompoZer? Keynote? Is it something that's useful enough and learnable fast enough to be of use to non-programmers, or should I just forget about it and leave it to the experts?

All this is not easy.

And maybe I'm looking in the wrong places. But when I see examples, they are usually given of how you would do something, but presuming you already know why you're doing something, and just need the particular details of this system.

Now, it doesn't really matter if I have trouble with this, because so many really good ahk programmers put really good stuff, spectacular stuff, up on the forum. And they do it for nothing but the joy of doing it. And I am so thankful for this, and I really admire this work. So I am happy to see this discussion because it means these programmers are going to continue to work with autohotkey. And so it doesn't matter what people like me understand or not. But if one is talking about keeping ahk understandable to new people or people like me, well, let the programmers remember that some of us are not on your level, and will never be.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Firstly (as a general request), please don't ask questions that can be answered by running the alpha. Also, don't make suggestions without first trying the alpha. There are a lot of comments to go through, and there is only so much time available to me. The more time I spend here, the less time I have for real development.

SplashImage and Progress: I need a volunteer to write an alternative script function before I will remove these commands. Also, I realized that SplashTextOn is just an inflexible version of SplashImage/Progress, so I plan to remove it. I'm sure it would be simple to script an alternative, if one was needed.

Multi-statement comma: it has its uses. If you don't know them, you don't need to use it. The change I made to it was purely to make its behaviour more logical and consistent with other languages, not to add any new capability.

The changes to #DerefChar were made primarily to allow experimentation for the alpha. I have decided against $var, $var; and ${var} as discussed in the plan, so I'll remove #DerefChar sooner or later. #CommentFlag and #EscapeChar will also be removed. I will not add any new directives aimed at "customizing" the language.

"IF" will not require parentheses. However, there probably isn't much use in IF (string1) string2 (auto-concat), so perhaps it can be detected as an IF with same-line action. Then again, maybe it's better not to introduce that subtle ambiguity.

I don't plan to add any functionality to URLDownloadToFile at this stage. However, changes may need to be made to allow for new features later on. For instance, if OutputVar := Download(URL) will become supported, the command form should probably be Download, [OutputVar], URL [, File]. Alternatively, it might be possible to use the unique form of the URL to disambiguate; i.e. allow Download, <!-- m -->scheme://location<!-- m -->.

= is comparison and := is assignment. This was discussed in great depth, and Chris seemed in favour of a dual-purpose equals sign. However, I am not Chris. See v2 Issue: Equal sign (=) used to both assign and compare.

+ is addition and & is bitwise-AND. Both support numeric strings. If I change the concat operator, it will be to remove ambiguity, not to replace it with more ambiguity. Probably the only one with a chance of being implemented is a..b, from Lua. As an aside, UnrealScript uses $ and @ to concat; the latter places a space between the two operands.

Rather than arguing that literal assignment should be kept because expressions are difficult to use with continuation sections, consider what the real problem is: spreading a string across multiple lines. There are other solutions to that problem which aren't contrary to the goals of v2. For instance, I like the idea of Python's triple-quoted strings.

Consider what a double-deref really is: Array%i% retrieves the contents of i, appends it to "Array" and searches the script's array of variables for a variable with that name. It's nothing more than Script.Vars["Array" . i]. Thus, mostly anything you can do with double-derefs can be done with arrays. (However, the reverse is not true.)

There might be some optimization potential to AHKs window Class/ID handling.

Do you have any specific ideas?

Any plans to support optional typing of variables?

No. I do not believe the benefits would be tangible if built on the current interpreter. However, there probably isn't any reason it can't be added after v2 if I change my mind.

Does this call InStr() or Var() ?

Does MsgBox %Var% deref the InStr var? The answer is the same. Perhaps MsgBox %(Var(...)) or %Var(...)% would be clearer.

if literal assignments are kept, I think @= would be better than `=

Why? I think it is neither "prettier" nor more intuitive. `= is a "literal assignment" just as `% is a literal percent sign and `, is a literal comma. ` is also easier to associate with strings than @.

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?

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?

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.

MasterFocus
  • Moderators
  • 4323 posts
  • Last active: Jan 28 2016 01:38 AM
  • Joined: 08 Apr 2009
Sorry I'm late. Have not been able to check the forum for a while.
I have not read everything posted so far, but I do agree with everything that fincs said here (his first reply).
Except for...
1- "if var between" - I'd like to see it as a function, not removed
2- StringSplit and RegExMatch outputing an object - I'm not that used to working with objects, so I have no opinion

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Antonio França -- git.io -- github.com -- ahk4.net -- sites.google.com -- ahkscript.org

Member of the AHK community since 08/Apr/2009. Moderator since mid-2012.