v2.. Scope Creep

[guest3456]

Seeing the v2-a90 release with the addition of closures and nested functions and fatarrows brought to mind some old quotes:

The focus of v2 is on changes that cannot be made in v1 due to backward compatibility. As such, new features which do not require a break in compatibility are outside the scope of v2.

In light of this, it seems best to make v2 not primarily about "new features" because that would produce a costly delay in its release.

However, I am determined to finish the project, and I hope that 2017 will be the year.

I'm aware that work on this project depends solely on your motivation, but thought maybe a reminder was applicable.

[nnnik]

clojures and nested functions and lamda expressions are an absolute must have for a language which selling point it is to define callbacks to hotkeys.

[just me]

Hi guest3456,

I totally agree with you..

[lexikos]

If I get bored, everyone loses.

I have previously tried to focus exclusively on v2 at times (I even more or less decided to stop v1 development several years ago). Rather than actually helping v2 progress, it merely caused me to lose interest and develop nothing for long periods. Working on anything interesting related to AutoHotkey is good for progress, even if it doesn't relate to the purported goals of v2.

Closures are something I've been interested in implementing for several years. My thoughts kept returning to it, and it only became clear recently that it could be implemented within the current "framework". Now that I've implemented it, I can stop thinking about how to implement it.

Would this topic have come up if I had implemented it in v1 and then merged to v2? The real reason I didn't implement it in v1 has nothing to do with the goals of v2; I merely didn't want to do the extra work that would be needed due to the differences in the two code bases.

However, closures have ramifications for v2; for instance, they supersede subroutines inside functions, which have (or for v2, had) a number of limitations that cause confusion.

[Helgef]

@ guest3456, you need some icing on the cake, or no one will buy it .

However, I am determined to finish the project, and I hope that 2017 will be the year

There should be no hurry.

clojures and nested functions and lamda expressions are an absolute must have for a language which selling point it is to define callbacks to hotkeys.

FYI, if you didn't notice, callbackCreate (former registercallback) accepts function objects .

[guest3456]

Would this topic have come up if I had implemented it in v1 and then merged to v2?

Good question. I imagine I probably would not have had these thoughts if these were built for v1 and then merged in

Working on anything interesting related to AutoHotkey is good for progress, even if it doesn't relate to the purported goals of v2.

Yeah, I do agree with this. I find these new features interesting as well.

But there will always be more interesting and edgy things to build. I'm just wondering if this thing will ever ship. Why not just rename v2-a90 to v2.0 and lets get rolling? What still needs to happen to release v2.0?

[Flipeador]

What still needs to happen to release v2.0?

IMO, most thoughts for v2.0 should be implemented; and a part of them will have a significant impact on the code. Old operating systems such as XP should not be considered.

[kczx3]

I'm just wondering if this thing will ever ship. Why not just rename v2-a90 to v2.0 and lets get rolling? What still needs to happen to release v2.0?

+1

Obviously you never want to rush a product into GA (though v2 is already available to anyone who wants to use it).

[SirRFI]

Why not just rename v2-a90 to v2.0 and lets get rolling?

Keeping v2 in alpha stage allows to make changes that would break scripts made for previous versions - syntax, parameter order or some base functionality. Official release would encourage some people to move over v2, including starters, where such changes are rather unwanted. Of course it may happen earlier or later, but that's not as much freedom.
Don't get me wrong - I want 2.0 to be out as well, but I want it to have as much time it needs, so we don't stick to some bad solutions like v1 has.

[SOTE]

Closures and nested functions are definitely great (so don't get me wrong), but I'm kind of the opinion they are more of a luxury (for an automation orientated language) or not so necessary except in a minority of cases. A lot can still be done with AHK v1 and subroutines inside of functions (https://www.autohotkey.com/docs/Functions.htm#gosub), if a user is insistent or find it necessary to stuff the maximum utility inside of a function versus breaking it out over two or more functions.

It's likely many AHK users (including those from AHK Basic and years back or coming from using the BASIC programming language) might have started out or leaned on using a lot of Labels, Gosub, Goto, etc... Debatably, this approach helps make AutoHotkey easier to learn. Once they switched over or started to use functions more, it would be quite easy to use Labels for subroutines inside of a function. Yes of course nested functions can do the same within a function, but I'm referring to how various people might have progressed or have been using a lot of Labels (to include Hotkey Labels) in their code, so using them in functions could be easier. Clearly those coming from other programming languages that don't or rarely use Labels, Goto, Gosub, etc... might feel weird about it.

Interestingly the Object Pascal programming language has Labels, Goto, and nested functions. So in that regards, AHK v2 would have company, where various options are possible. Also, having closures, nested functions, and fat arrows kind of gives AHK v2 a more JavaScript or Swift type of feel. And I don't think it bad for AutoHotkey to take inspiration from those languages. If someone who started out in AutoHotkey were to take on learning other languages, I would think it can make it an easier jump to JavaScript or Swift, and maybe including Object Pascal or Go. Swift would probably be very comfortable for many AutoHotkey users, unfortunately it's more macOS orientated.