extend ahk with custom built-in variables? Topic is solved

[swagfag]

i was wondering if there was a way to achieve the following:

Code: Select all

MsgBox % A_MyCustomBIV

whereby the variable actually does some computations in the background, so its not just a plain old var defined somewhere
basically like a function, but without the parens

[Helgef]

No

[swagfag]

oh well

thanks

[jeeswg]

- Can AutoHotkey_H do this?
- Anyhow, adding in A_ variables via C++ and compiling is not so difficult. Cheers.
AutoHotkey C++ Powerhouse: Introduction - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 23&t=54394
- I thought about this as a feature request, however, it's ultimately just a function call minus 2 characters (parentheses), for an increased parsing burden. On the flipside, it would facilitate backporting future A_ variables. It could also allow read-only and special variables ...
- Adding Int / Str etc as special variables might be useful if this went through.
Disabling unquoted argument and return types for BIF_DllCall. by HelgeffegleH · Pull Request #121 · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/pull/121

[eqv]

i was wondering if there was a way to achieve the following:

Code: Select all

MsgBox % A_MyCustomBIV

whereby the variable actually does some computations in the background, so its not just a plain old var defined somewhere
basically like a function, but without the parens

Hello, if you don't mind putting a dot ("."), you can use classes (object-oriented, although I personally don't like) and put then in your library:

Code: Select all

Msgbox % A_.MyCustomBIV

Class A_ {
	Static MyCustomBIV:=(A_Hour ":" A_Min ":" A_Sec)
}

Here is another example, with more stuff:

Code: Select all

Msgbox % EXAMPLE.VAR1
Msgbox % EXAMPLE.VAR2
Msgbox % EXAMPLE.VAR3

Class EXAMPLE {
	Static VAR1:=(A_Hour ":" A_Min ":" A_Sec), VAR2:=(A_YYYY "/" A_MM "/" A_DD), VAR3:=FUNCTION()
} FUNCTION() {
	Return, "Just a function example, you can do complex stuff."
}

To learn more about object oriented; check the documentation:
https://autohotkey.com/docs/Objects.htm#Custom_Classes

Greetings,

[nnnik]

In my opinikon A_ variables in general are bad practice and a bad idea.
The user cannot create their own A_ variables and using A. instead of A_ makes no difference (other than byref which is cancer anyways).

[Helgef]

@ eqv, remember that built in variables aren't super global, they are available everywhere (except a_args if I recall correctly), so in an assume local function you have to declare global a_. BTW, use properties instead of external functions.
Anyways, you shouldn't name your variables something starting with a_.

I agree nnnik .

Cheers.

[jeeswg]

- Perhaps it is worth considering the AHK v2 String() function, which could be backported to AHK v1. String(var) would give a string for a Float/Integer/String, and would call var.ToString() for an object.
- Perhaps the Integer and Float functions could handle objects with ToInteger and ToFloat methods.

- Also, in theory, some functions could have improved handling for objects, e.g. in AHK v2 WinXXX functions check any objects for an Hwnd method.

- (I would prefix variables with 'vGbl' or possibly 'AX_', but not 'A_'.)