Updated from v2-108 to v2-112. Just a bliss! Feels so good. But a [list of bugs/suggestions]

Discuss the future of the AutoHotkey language
User avatar
vvhitevvizard
Posts: 337
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated from v2-108 to v2-112. Just a bliss! Feels so good. But a [list of bugs/suggestions]

30 Jun 2020, 04:47

@lexikos
21... a .b is obviously invalid if a has no b property. Strings have no b property by default.
Thank u for explanation. Lines concatenation rule seems to be overmastering here. What a pity.

12... How many functions must you define in global scope, that you need to cram them onto one line?
Speaking of my style, I use macros and lambdas in other languages to shorthand stuff. For AHK, pretty much the majority of functions I have to use outside classes and yet not as closures. I find it very convenient. Example 1: 2 lines instead of ~30:

Code: Select all

;shorten digits length with KMG, round to precision, trim. negative nums NOT SUPPORTED
	numS(_n,n:=0,k:=1000)=>(n:=0+_n, s:=(n<k) ? "":((n/=k)<k) ? "K":((n/=k)<k) 
		? "M":((n/=k)<k) ? "G":((n/=k)<k) ? "T":((n/=k)<k) ? "P":"ERR", numP(n) . s)
Please note I had to "allocate" 2 local vars n and k in function's parameters here.
Ironically that's similar to stack frame concept. But it deprives me of discerning the fat-arrow function calls with an excessive number of parameters and/or wrong value in place of "allocated" vars.

example 2: Usage of regular function bodies with curly brackets and commands would double and even triple the lines number (aside from comments):
Example of GDI+ callouts

local context namespace by default should be for everything inside "curly brackets" - class declaration, function body, object's members declaration member:value inside {} and so on - I do believe global-assume for => operator is irregularity. A quirk of AHK V2.

23. You can do whatever you want by overloading the __Item property.
Performance-wise its not worth it. Especially for inner loops: according to my testing (for previous v2-108) it degrades the performance by 2-5%.
Actually I gave up and just use non-zero indexing. My point 23 is to make sure all the remnants of zero indexing r removed by default.
Last edited by vvhitevvizard on 30 Jun 2020, 07:23, edited 2 times in total.
User avatar
vvhitevvizard
Posts: 337
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated from v2-108 to v2-112. Just a bliss! Feels so good. But a [list of bugs/suggestions]

30 Jun 2020, 05:57

v1.1.33 and v2.0-a113 will catch the stack overflow exception and display a message. By that point, the entire call stack will have unwound, so there will be no chance of recovery.
:thumbup:
lexikos wrote:
29 Jun 2020, 23:08
16... I have no idea what you're talking about.
I try to rephrase what I meant: For a script that persists for long time (days) unmanned and do some maintaining work to have the chance to terminate in a way to save some critical data or (if there is no recovery chance) at least to let the user know when-and-why it has happened by leaving some final log message/etc. After all, even just a modal msgbox with error text stating date/time and the stack overflow cause would be ok, too. Cant wait for V2-113
15... So do FileRead (with the RAW parameter) and other functions, for other types of objects. Maybe there will be other functions that return an IO object.
I just meant all the AHK built-in object creation syntax to be unified since u implemented .new method instead of new operator. ;)
6... But incorrect code will make your program not work. Is it better to fail quickly?
It doesn't try to change or assess returned data whether it has a special meaning or not aside from stringifying it out. it expects key-value pairs of valid AHK entities (let it be even empty strings) to be returned for for key,value in obj that has __Enum property. Ofc a script programmer can stuff up as many kludges as possible to make it go thru possible errors. But claiming "I have enumerator" (cuz __Enum property has that special meaning officially documented) and failing to return an enumerable value is a flaw for a built-in object. Actually, I cant recall any other case of for-in throwing itself instead of just concluding in case no values left to enumerate.
17... I live in the real world (for some of the time), and can't recall ever encountering a need for what you describe, in AutoHotkey.
A memory region returned by outer library. Let's say we don't wanna copy it but to patch it yet using buffer-aware functions. Also, closely following the AHK V2 trend, I have an impression that exploiting binary memory regions without declaring them as a buffer object might be restricted in the future.
You are free to hate and blame, but it changes nothing.
Haha I tried. To be honest, u r a genius yet known of being extremely conservative sometimes. I still recall it took over 5 years for u to finally yield to .Count() method implementation for Array despite of multiple requests and hackery topics working around this drawback.
U might be very irritated by me but I just run risks of bumping up other ppl's pleading - voting among true AHK V2 adepts shows they don't really think commands have to be in the language: https://www.autohotkey.com/boards/viewtopic.php?f=37&t=40169
By saying that command syntax is not a payload but a burden, I do realize removing command syntax COMPLETELY is not an easy task.

PS: Thank u for ur time! And I beg ur pardon in case some of my statements r hard to understand - I'm not a native English speaker.
lexikos
Posts: 6854
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Updated from v2-108 to v2-112. Just a bliss! Feels so good. But a [list of bugs/suggestions]

30 Jun 2020, 16:42

I've no idea what you intend by linking to my post, which explains that the example problem under discussion would have been even more problematic without the function call statement syntax.
numS(_n,n:=0,k:=1000)=>(n:=0+_n, s:=(n<k) ? "":((n/=k)<k) ? "K":((n/=k)<k)
? "M":((n/=k)<k) ? "G":((n/=k)<k) ? "T":((n/=k)<k) ? "P":"ERR", numP(n) . s)
That's terrible, and not something I would ever want to encourage.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 22 guests