@SOTE I think your advocacy of labels relates specifically to the use of labels
as subroutines. I do not understand why you believe that label-subs are easier than functions. In general terms, there are two ways to define and call a subroutine:
Code: Select all
name: ; starting point
body
return ; ending point
gosub name ; call
Code: Select all
name()
{ ; starting point
body
} ; ending point
name() ; call
What's harder about the function? Okay, the author might need to be aware of
scope; or not.
Using this pattern does not require any understanding of scope or local variables.
On the other hand, maybe the subroutine doesn't need access to global variables, and having automatic access can cause problems. Global namespace pollution is as much or more of a problem for beginners, who aren't aware of it, than advanced programmers. Local variables are a very basic concept.
If you forget to define the ending point of a label-sub, as beginners often do, you will not be notified, and the program will behave incorrectly. It is both less likely that you will forget the ending brace of a function and less likely that the problem will go unnoticed, as the program will alert you to mismatched braces.
Label-subs do not necessarily have a clearly-defined ending point. They end wherever execution ends. That could be inside some deeply nested function call which calls
Exit or raises a runtime error. Maybe the subroutine actually never ends (loops infinitely).
Using functions in no way requires any understanding of objects, classes, methods or any other OOP feature. A function is just a subroutine that
optionally accepts parameters and
optionally returns a value.
Functions were implemented long before objects or any OOP feature.
SOTE wrote: ↑10 May 2019, 04:36
In AHK v2, it appears that g-labels are gone. The AHK v1 g-labels are simple to use, when the person knows what the letter g stands for, and easily connects to the concept of using labels.
OnEvent is simple to use, when the person can read English, and easily connects to the concept of calling a function.
If labels will stay, didn't see why they couldn't be accessed from a GUI control (like say a button) in a direct manner.
Obviously, if it could be done with a helper function, it could be done in a direct manner. However, g-labels often depend on the presence of global variables for passing
parameters such as which gui or control, x and y coordinates, size, the type of event, or something else relating to the event. When a subroutine needs to accept parameters, the appropriate construct to use is a
function.
When I added support for functions and function objects in place of labels in v1, I had to give precedence to label names over function names for backward-compatibility. After the addition of nested functions in v2, there is now no compelling reason to recommend a label over a function. That being the case, one advantage of removing label support is that I will not need to explain my recommendation to new users.
Other drawbacks to the v1 implementation of g-labels include: The type of event is sometimes represented cryptically, as a single letter. Some events are used less often than others, so are disabled by default, requiring the use of the obscure "AltSubmit" option to enable them. "gsomething" inhibits visual distinction of the label/function name, finding it with "match whole word only", and selecting the name by double-click or similar.
... it's more about what comes along with functions (classes, methods, objects, etc...).
If a user learns how to use those things, they will be better off, but it is not necessary. One can learn by example how to write GUI code with the new API, without learning all of the details about how objects work.
Classes are simply not needed (but some users find it helpful to use them, and can with the new API). If your problem is with
OnEvent, the debate of labels vs. functions is tangential. After all,
the g-label option also supports functions.
Labels, when understood, are often all the user needs to create programs to do various simple tasks.
If a label is all you need, you can replace it with a function and do not need to use or learn anything extra, other than local variables (or alternatively, the need for
global).
AHK v1 GUI syntax might not be so awkward to a lot of people, because of tools like AutoGUI and SmartGUI Creator.
Such tools can be updated for v2. Users who aren't dealing with the syntax won't care whether it uses commands with sub-commands or objects.
Thus g-labels are very easy to use. Users can/are simply assigning actions to labels.
If the user creates a GUI via a GUI and then is only defining the event handler, how is a g-label any easier than a function? With OnEvent, there is a one-to-one connection between an event and a function. The user can select a control and event, click a button in the GUI creator, and it can generate the OnEvent call and function. All the user needs to do is write code that should execute when that event is raised.
By contrast, g-labels often require checking global variables to find out which event happened.
Why must AutoHotkey syntax be a copy of JavaScript, Python, AutoIt, etc...?
Why would you leap to the conclusion that how
other languages do things is motivating these changes? AutoHotkey has expression in v1. Expressions can do everything that the legacy syntax can do, so there is no need for the legacy syntax. I reject the point of view that the legacy syntax is easier, especially since it must inevitably be mixed with expression syntax.
Other languages are often very similar because this is the right way to do it.