Updated to v2-a136. [list of 51 suggestions]

Discuss the future of the AutoHotkey language
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Updated to v2-129. [list of 51 suggestions]

Post by just me » 14 Mar 2021, 07:37

=> #49

Code: Select all

N := 7775
MsgBox(LTrim(7775, "7"))      ; number   -> 7775
MsgBox(LTrim("7775", "7"))    ; string   -> 5
MsgBox(LTrim(N, "7"))         ; variable -> 5

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-129. [list of 51 suggestions]

Post by vvhitevvizard » 14 Mar 2021, 07:46

@just me Exactly. It takes everything as 1st param and silently converts it and that is a standard AHK behavior.
But the function's documentation article is confusing:
Any string value or variable. Numbers are not supported.
One might infer that pure numbers are not supported. IMHO, it better be replaced with -> Any string/pure numeric value or variable.

just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Updated to v2-129. [list of 51 suggestions]

Post by just me » 14 Mar 2021, 08:06

... numbers are not supported -> the function won't change 'pure numbers' passed as the first parameter. (I cannot imagine any 'real world example' passing a pure number or a literal string to the function).

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-129. [list of 51 suggestions]

Post by vvhitevvizard » 14 Mar 2021, 09:46

just me wrote:
14 Mar 2021, 08:06
... numbers are not supported -> the function won't change 'pure numbers' passed as the first parameter.
...
MsgBox(LTrim(7775, "7")) ; number -> 7775
Finally I got what u mean! :D
Then it seems even more weird to me - it neither defaults to converting literal (immediate) numbers to strings (being a string conversion subset) nor throws an error yet it converts pure numbers stored in variables... There should be no difference between accepting an evaluated expression/literal number and accepting a pure number stored in a variable.
(I cannot imagine any 'real world example' passing a pure number or a literal string to the function).
Neither can I. But the case leads me personally to the state of cognitive dissonance. :?

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Updated to v2-129. [list of 51 suggestions]

Post by lexikos » 20 Mar 2021, 23:53

It's just a bug. Trim returns the string immediately if it was just converted from a pure number, since it's known that there is no leading or trailing whitespace, so no trimming is needed. (It fails to take into account the second parameter.)

This doesn't affect variables due to a holdover from v1: variables always have their own string buffer, which is used to cache the numeric string in this case. The conversion from number is not detected because Trim only compares the string's address to the conversion buffer, which isn't used for variables.

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-129. [list of 51 suggestions]

Post by vvhitevvizard » 19 Apr 2021, 07:34

So many changes recently again! Very good trending, at first glance:
Changed IsSet(var) to check var itself and added IsSetRef(ref).
Brilliant solution! consistent and logical. :thumbup:
Replaced #Persistent, #InstallKeybdHook, #HotkeyInterval etc
@Lexicos Good to see u've decided to start addressing these #directives' mess! I hope all the remaining irrelevant ones for preprocessor stage will be replaced with built-in functions/variables.

Only gripe for
New uses for Else
In my opinion, that's somewhat unusual and requires to pay much more attention when upgrading from previous AHK versions and converting from other languages. But it remains to be seen for real case scenarios like upgrading 40k lines code base from v129 to v132 in my case. :)
Last edited by vvhitevvizard on 19 Apr 2021, 09:36, edited 1 time in total.

quaritexa
Posts: 32
Joined: 09 Nov 2017, 21:03

Re: Updated to v2-129. [list of 51 suggestions]

Post by quaritexa » 24 Apr 2021, 07:01

@lexikos
This code stopped working with the last update (132):
---------------------------
AHK_CQT_406662437
---------------------------
Error: Syntax error.

Line#
003: a := "b"
004: c := {b: "blah"}
---> 005: msgbox(c.%a%)
006: Exit

The program will exit.
---------------------------
OK
---------------------------

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-129. [list of 51 suggestions]

Post by vvhitevvizard » 24 Apr 2021, 07:51

quaritexa wrote:
24 Apr 2021, 07:01
This code stopped working with the last update (132):
msgbox(c.%a%)
yeah, many ppl have reported this bug. :D Its fixed in the upcoming update:
https://www.autohotkey.com/boards/viewtopic.php?f=14&t=89557

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Updated to v2-129. [list of 51 suggestions]

Post by lexikos » 24 Apr 2021, 20:22

vvhitevvizard wrote:
19 Apr 2021, 07:34
New uses for Else
In my opinion, that's somewhat unusual
That's ironic, considering you seem to be a fan of Python, which is where I got the idea.

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-129. [list of 51 suggestions]

Post by vvhitevvizard » 25 Apr 2021, 07:09

That's ironic, considering you seem to be a fan of Python, which is where I got the idea.
haha. I meant its not usual to conventional syntax like in C/Pascal/etc. But main concern was that it would render some code fragments to behave differently w/o flagging an error - the same caveat as with the brief moment between updates when u let methods to be rewritten as properties in an ordinary way. But anyways in practice I didn't bump into any issues while converting to v2-a131. :thumbup:

I like some Python's syntax elements and do use Python due to some specific 3rd party libraries like machine learning support existing mainly only for Python, tho I never converted or planned to convert any of my AHK scripts into Python simply because as soon as they function they require less resources and less dependant on 3rd party libraries overall.
Removed BufferAlloc() and added constructor for Buffer().
@lexikos thank u for this!
obj:=fileopen() -> obj:=File() ? :D Same logic just to complete unification of built-in objects construction.

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Updated to v2-129. [list of 51 suggestions]

Post by lexikos » 25 Apr 2021, 21:09

But main concern was that it would render some code fragments to behave differently w/o flagging an error
There are many such cases throughout the changes from v1 to v2. This particular change is easy to detect through static analysis. I'm not even remotely bothered by issues updating from one alpha to the next.

I'd be more inclined to rename File to FileOpen than make File() open a file for reading/writing.

Post Reply

Return to “AutoHotkey Development”