Updated to v2-119. [list of 50 suggestions]

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

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 04:05

swagfag wrote:
28 Jul 2020, 20:11
40.
BTW, I don't quite understand the meaning of this (from V2-a118):
Revised implementation of for: Increased maximum number of variables from 2 to 19
Does it mean that now I can write for i,j,k,l,m,n in customobj.enumerator?
Helgef
Posts: 4459
Joined: 17 Jul 2016, 01:02
Contact:

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 04:08

Revised implementation of for: Increased maximum number of variables from 2 to 19
Does it mean that now I can write for i,j,k,l,m,n in customobj.enumerator?
Yes, eg,

Code: Select all

for x,y,z in (byref a, byref b, byref c) 
	=> ( 	
		a := random(1,10),
		b := random(11,20),
		c := random(21,30),
		random(0,5)
	)
	msgbox x . '`n' . y . '`n' . z
msgbox 'done'
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 04:37

Thx for quick reply, @Helgef! It looks great.

@swagfag
40. well, what about "For map enumerator to return key is quite convenient cuz value can be obtained via KEY."?
Yes, map and array enumerators don't correspond to each other's key/value preference. We just need a unified (expected) rule here. Arrays r more commonly used. Solution would be to restrict map enumerator to 2 values mode only OR 1-value for-loop to return KEY for both array and map.
41.can be done if __Set(Name, Params, Value) { } had Value swapped over to 2nd, with Params* becoming the new variadic parameter.
yeah! I suppose its better to re-design old and future built-in functions to have variadic params* to be the last in the parameters list.
swagfag wrote:
28 Jul 2020, 20:11
34.
VERY good explanation! :thumbup: So basic complaint of #34 is irrelevant (I updated OP) BUT it has a continuation! I accidentally discovered an issue: https://www.autohotkey.com/boards/viewtopic.php?p=342033#p342033
.ownmethods() returns no methods for instanced class objects.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 07:34

Helgef wrote:
29 Jul 2020, 03:21
For some unknown reason it brings a dramatic slowdown for some scripts upto 8% compared to version V2-118!
This is not very useful information if we don't know what and how you measure this.
Actually I got quite a lot of real-world test files due to for every project I do have a benchmark mode. Here goes one of my mostly used json<->json test I started since AHK V2-89, with a few custom libraries. The code is permanently optimized. The current version is expected to run with AHK v118 and v119 versions only. Unlike some simple programmatically created loops to test performance, this one uses a real JSON data. It takes some time to execute. It has to be run several times to get the lowest run time - I didn't change test's outer cycle since the first version for calculated results' compatibility.
test2.7z
(7.65 KiB) Downloaded 20 times
(7-zip archive, https://www.7-zip.org)
I can recall only AHK V2-104 that brought quite remarkable slowdown. Other updates were around +/- 1% or less performance-wise.
looking at update description https://www.autohotkey.com/boards/viewtopic.php?p=343965#p343965, I'm at my wits end what could cause that dramatic slowdown.
Raw numbers for different environments may greatly differ, one should note % increase compared to prev/next version performance. For my system:

Code: Select all

;6390  v2-119 (8% as slow)
;5875  v2-118
;5907  v2-116
;5750  v2-113
;6015  v2-108
;5810  v2-103
;5730  v2-102
EDIT: I updated #39 in OP concerning #requires
Request: ability to set a range, e.g. v2.0-a103, v2.0-a107 with comma or just whitespace between version numbers. E.g.:

Code: Select all

#requires AutoHotkey v2 ;doesnt work with AHK V1 or AHK V3, tries to run with any AHK V2 version
#requires AutoHotkey v2-a116 ;works with this exact AHK V2 version ONLY.
#requires AutoHotkey v2-a116 V2-a119 ;expects only this range of AHK versions.
Last edited by vvhitevvizard on 30 Jul 2020, 07:48, edited 10 times in total.
iseahound
Posts: 611
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Updated to v2-119. Just a bliss! Feels so good. But a [list of 42 suggestions]

29 Jul 2020, 07:36

vvhitevvizard wrote:
28 Jul 2020, 08:54
getpos(*x,*y,*w,*h)
getpos(out x, out y, out w, out h) syntax looks even better!
There is no point in introducing new syntax when what we have getpos(x:=0, y:=0, w:=0, h:=0) works fine. It is not even verbose. If you skim through the link,it suggests that tuple types be used for multiple return values instead. This is the same approach that Python uses. No other language (that I could find), aside from C# and AutoHotkey even has an out parameter. Most languages even lack byref parameters. A tuple type for multiple return values would be better:

Code: Select all

(x,y,w,h) := getpos()
SetWindowPos((x,y,w,h)*)
; or
SetWindowPos(GetPos()*)
Out parameters are mostly for DllCall anyways.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. Just a bliss! Feels so good. But a [list of 42 suggestions]

29 Jul 2020, 07:50

iseahound wrote:
29 Jul 2020, 07:36
There is no point in introducing new syntax when what we have getpos(x:=0, y:=0, w:=0, h:=0) works fine.
My complaint concerns #warn UseUnsetLocal.

So instead of assigning some value just to appease warning dialogues:

Code: Select all

;function start:
local x:=0, y:=0, w:=0, h:=0
;...
getpos(x, y, w, h)
;x1:=x, y1:=y
;...
customfunction(14,77,0,0,x,y)
x2:=x,y2:=y
we could increase legibility by indicating which variables r initialized outside the function. There r such additional keywords in other languages like volatile modifier in C/CPP that tells the compiler a variable can be modified/initialized outside (otherwise it would be simply removed via optimization). AHK could do additional checks on out variables and/or drop some warnings concerning their assignment.
Out parameters are mostly for DllCall anyways.
Many custom functions use byref arguments for output - sometimes its more convenient to use several output vars instead of wrapping in/out parameters in an object. Recently added mentioned guicontrol.getpos() built-in method uses up to 4 output vars.

Also, the current syntax concerning passing a byref output variadic arguments is kinda cumbersome:

Code: Select all

function(byref _c:=unset){ ;We don't need a byref output variable to be initialized here and its variadic and may be skipped as well
  ;if _c argument is passed we assign a value to it:
  isset(_c) && _c:=1 ;or isbyref(_c) 
}
EDIT: So my proposal is not to make out keyword mandatory, but to give a script writer 3 choices:
1. disable all warnings with #warn and have some output variables unassigned.
2. explicitly assign some values to them, e.g.: getpos(x:=0, y:=0)
3. do not assign any values but declare them as output variables: getpos(out x, out y)
Last edited by vvhitevvizard on 29 Jul 2020, 11:56, edited 3 times in total.
iseahound
Posts: 611
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 08:02

https://www.autohotkey.com/boards/viewtopic.php?f=37&t=75049

Again, tuples would be nice. Barring that, an array or an object.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 08:18

iseahound wrote:
29 Jul 2020, 08:02
https://www.autohotkey.com/boards/viewtopic.php?f=37&t=75049
Again, tuples would be nice. Barring that, an array or an object.
I use tuples (unmodified lists) here and there in Python, the more types we could have in AHK the better! no doubt about it.
But I touch the current AHK version status quo here. Definitely, I could just use an array or an object to pass or get parameters in AHK right now, but the syntax for addressing a returned value as a complex object arr[1], obj.x, etc might be cumbersome in some cases, object addressing performance is lower compared to primitive variables, add here AHK quirk of object members addressing being an expression so that obj.x cannot be passed directly as an output variable for another function call. Byref variables passed as arguments r not copied into local shadows while remaining primitive and I find it useful for passing a few output variables.
Most languages even lack byref parameters.
They have alternatives (pointers, references).
SOTE
Posts: 1061
Joined: 15 Jun 2015, 06:21

Re: Updated to v2-119. Just a bliss! Feels so good. But a [list of 42 suggestions]

29 Jul 2020, 12:03

iseahound wrote:
29 Jul 2020, 07:36
No other language (that I could find), aside from C# and AutoHotkey even has an out parameter. Most languages even lack byref parameters.
Hmmm... Maybe you are not looking into it that hard. Object Pascal has both. Out parameter is called exactly that. As for byref, as it's called in AutoHotkey, it is often referred to as pass by reference or call-by-reference.
iseahound wrote:
29 Jul 2020, 08:02
https://www.autohotkey.com/boards/viewtopic.php?f=37&t=75049
Again, tuples would be nice. Barring that, an array or an object.
In agreement. But fine with AutoHotkey's objects.
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Updated to v2-119. [list of 45 suggestions]

29 Jul 2020, 13:29

vvhitevvizard wrote:
29 Jul 2020, 04:37
@swagfag
40. well, what about "For map enumerator to return key is quite convenient cuz value can be obtained via KEY."?
Yes, map and array enumerators don't correspond to each other's key/value preference. We just need a unified (expected) rule here. Arrays r more commonly used. Solution would be to restrict map enumerator to 2 values mode only OR 1-value for-loop to return KEY for both array and map.
The single advantage of an enumerator/iterator over accessing each index by its value one after another is speed.
The enumerator has introspection into the containers internal structure and can pick the next set of values without any kind of delay.
A lookup in a Map in comparison either involves calculating a hash and then locating it in a list or going down a tree structure of comparisons.

We would slow down the entire loop not by "drastic" 8%.
For HashMaps I would assume the difference would be around 500% slower in comparison to the normal iterator.
For Dictionaries (what we currently use) we have an entire shift in the complexity of the operation "Iterate".

Reducing an iterator to a single variable type for the sake of consistency and "Because you can get the value from the key" very much defeats the point of using an iterator in the first place.
So no this suggestion will never be a thing.
Recommends AHK Studio
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

30 Jul 2020, 06:43

nnnik wrote:
29 Jul 2020, 13:29
The single advantage of an enumerator/iterator over accessing each index by its value one after another is speed.
U r absolutely right here. I've just tested loop array.length {array[a_index]} vs for v in array {v} vs for k,v in array {v} using AHK V2-118. My dbg class measures average, minimum, maximum per 1 loop out of 10000 runs. Results (in microseconds per 1 cycle):

Code: Select all

;550000|550000|550000
;1. loop array.length | min:2.1 max:17.4 avg:2.3
;2. for v in array | min:1.4 max:11 avg:1.6
;3. for k,v in array | min:1.5 max:16.7 avg:1.6
So 1-variable for-loop wins: it takes minimum 1.4mcs on my machine, and both for-loop variants have an enormous lead over loop

test suit (edited - I moved all the initializations to the 1st line):

Code: Select all

a:=[1,2,3,4,5,6,7,8,9,10], c:=d:=e:=_1:=_2:=0
dbg.reset()

loop(n:=10000){
	dllcall('QueryPerformanceCounter', 'int64P',_1)
	loop(a.length)
		c+=a[a_index]
	dllcall('QueryPerformanceCounter', 'int64P',_2),  dbg.add("loop array.length", _1,_2)
}
loop(n){
	dllcall('QueryPerformanceCounter', 'int64P',_1)
	for v in a
		d+=v
	dllcall('QueryPerformanceCounter', 'int64P',_2),  dbg.add("for v in array", _1,_2)
}
loop(n){
	dllcall('QueryPerformanceCounter', 'int64P',_1)
	for k,v in a
		e+=v
	dllcall('QueryPerformanceCounter', 'int64P',_2),  dbg.add("for k,v in array", _1,_2)
}
msgbox(a_clipboard:=c "|" d "|" e "`n" dbg.dump())


;//////////////part of ww_dbg.ahk2:

class dbg{ ;v1.2
	static add(_s, _a, _b){ ;add current iteration time _s:checkpoint name, _a:start time, _b:stop time
		o:=dbg, d:=time.ticks2mcs(_b-_a)
		;a:min,b:max,c:counter,s:sum
		o.k.has(_s) ? (r:=o.k[_s], r.c++, r.s+=d, d<r.a && r.a:=d, d>r.b && r.b:=d) : o.k[_s]:={a:d,b:d,c:1,s:d}
	}static dump(){ ;print profiled data
		i:=0, s:=""
		for k,v in this.k
			s.= ++i ". " k " | " (v.c=1 ? num.p(v.a) : "min:" num.p(v.a) " max:" num.p(v.b) " avg:" num.p(v.s/v.c)) "`n"
		return s
	}
	static reset()=>this.k:=map()
}

;//////part of ww_str_num_bin_time.ahk2

class num{ ;v1.3.4
	static Decimals:=1 ;decimals for Round()
		, Precision:=6 ;num length for trimming/zero padding
	static p(_n){
		if(i:=instr(a:=ltrim(_n,"-0"),".",1)){
			p:=num.Precision, d:=num.Decimals
			r:=((i=1) ? (strlen(s:=substr(a,2))-strlen(ltrim(s,"0"))+p)
				: (i<=p) ? p-i+1:0) ;q should be >0: no rounding for the left part
			return rtrim(rtrim(round(_n, r>d ? d:r), "0"), ".")
		}
		else
			return round(_n) ;integer: just trim
	}
}

class time{ ;v1.1.3
	static ticks2mcs(_t){ ;perf counter ticks to mcs (microseconds)
		;The freq of the perf counter is fixed at system boot and is consistent across all processors
			;We query it upon app init and cache
		static f:=0
		;If the installed hardware supports a high-resolution perf counter, the retval is nonzero
		(f) || 	dllcall("QueryPerformanceFrequency", 'int64P',f)
		;To guard against loss-of-precision, we convert to microseconds *before* dividing by ticks-per-second:
		return(_t*1000000/f)
	}
}
Last edited by vvhitevvizard on 30 Jul 2020, 13:57, edited 1 time in total.
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Updated to v2-119. [list of 45 suggestions]

30 Jul 2020, 07:04

You need to use a much larger array to see the real difference between the 2 methods - e.g. 10k entries.
Recommends AHK Studio
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

30 Jul 2020, 07:11

nnnik wrote:
30 Jul 2020, 07:04
You need to use a much larger array to see the real difference between the 2 methods - e.g. 10k entries.
True. It gives a basic idea. It might yield even greater delta cuz we measure c+=a[a_index] inside loops and loop initialization takes some time.
I might insert perfcounter queries between this line inside the cycle and get more accurate result for arbitrary arrays including small ones.

Code: Select all

loop(n:=10000)
	loop(a.length){
		dllcall('QueryPerformanceCounter', 'int64P',_1)
		c+=a[a_index]
		dllcall('QueryPerformanceCounter', 'int64P',_2),  dbg.add("c+=a[a_index]", _1,_2)
	}
Results (0.2mcs vs 0.3mcs):

Code: Select all

550000|550000|550000
1. e+=v | min:0.2 max:146.4 avg:0.29
2. d+=v | min:0.2 max:59.5 avg:0.28
3. c+=a[a_index] | min:0.3 max:358 avg:0.44
c+=a[a_index] is 50% as slow compared to c+=v

That's why I requested for #36 in OP - it might yield the most accurate results cuz CPP side AHK function might be faster than dllcall('QueryPerformanceCounter', 'int64P',_1:=0): for simple AHK commands in-between we measure dllcalls themselves.
Last edited by vvhitevvizard on 30 Jul 2020, 09:32, edited 3 times in total.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 07:30

OP updated.

46. Revolt! Revolt! the majority wants command syntax to be completely removed. Some ppl do like to use function calls w/o (). How about a compromise: #nocommands (#commands off, #syntax strict, whatever) pre-processor directive to disable command syntax (forcing to use () for function calls) in the script being parsed so that f (37,38) lines would finally trigger a warning or error.

47. abbreviations for dllcall parameters types. Similar to AHK_H V2 branch (by @HotKeyIt) with DllCall's equivalent named DynaCall.

Code: Select all

Int	i
Str	s
AStr	a
WStr	w
Short	h
Char	c
Float	f
Double	d
PTR	p
Int64	i64
PTRP	pp, etc
I expect some scripts extensively using dllcalls to be reduced to the extent of 2-10%.
example:

Code: Select all

gp_ellipsefill(g,b, x,y,w,h)=>dllcall("gdiplus\GdipFillEllipse", 'ptr',g, 'ptr',b, 'float',x, 'float',y, 'float',w, 'float',h)
->

Code: Select all

gp_ellipsefill(g,b, x,y,w,h)=>dllcall("gdiplus\GdipFillEllipse", 'p',g, 'p',b, 'f',x, 'f',y, 'f',w, 'f',h)
DllCall could actually support both notations - regular and abbreviated at the same time for compatibility sake.
Last edited by vvhitevvizard on 30 Jul 2020, 19:18, edited 4 times in total.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 45 suggestions]

30 Jul 2020, 08:24

nnnik wrote:
29 Jul 2020, 13:29
Reducing an iterator to a single variable type for the sake of consistency and "Because you can get the value from the key" very much defeats the point of using an iterator in the first place.
So no this suggestion will never be a thing.
Performance-wise, its safe to say loop and a_index addressing for objects sux. :D What about returning a key for for k in array? it renders 1-var mode to be not so helpful for array forcing ppl use 2-vars mode for array, but as u can see according to the tests above, for k,v in array is just a tad slower, but by doing this, we bring consistency!
Last edited by vvhitevvizard on 30 Jul 2020, 08:33, edited 1 time in total.
Helgef
Posts: 4459
Joined: 17 Jul 2016, 01:02
Contact:

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 08:31

Performance-wise, its safe to say loop and a_index addressing for objects sux
I don't think so. Typically, when you use a for loop you create (and destroy) an enumerator object, and back-up and restore the loop variables. You can't index a map using a_index, in general.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 08:47

Helgef wrote:
30 Jul 2020, 08:31
Typically, when you use a for loop you create (and destroy) an enumerator object, and back-up and restore the loop variables. You can't index a map using a_index, in general.
Yeah, I have an idea how hashed indexing works for map and I try to use vanilla array over map whenever its possible, but I beg to differ for array under debate, even tho the best possible way to measure a single AHK command/expression within a script is not accurate enuf [yet], u can see for the test results, it [1-var vs 2-var mode] doesn't make much difference even for 10-members array cuz those actions r on CPP side.
So my last try to bring it to consistency is to propose a 1-var for-loop to return a key (essentially only changing for k in array implementation (but not for k,v in array or both for-loop for map), it forces to use 2-vars instead of 1 for old for k in array behavior).
So it would make it plain simple and logical: 1-var for-loop returns keys always, 2-var for-loop returns keys,values.

BTW, the majority of script writers uses 2-vars mode anyways so the transition may be not so painful.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 14:51

I'm tired but I guess I either bumped into something again or miss something. Candidate for #48?

Code: Select all

g:=gui.new(), f:=g.add("edit"), g.show()

msgbox(f.type)
try f.type ;Error: the value of type "Gui.Edit" has no method named "type". OH, REALLY?
catch e
	msgbox(e.message)
Error: the value of type "Gui.Edit" has no method named "type". Not expected:
1. it manages to msgbox(f.type) before failing try f.type
2. type is a property: https://lexikos.github.io/v2/docs/objects/GuiControl.htm#Type yet the error description complains about "a method".
Last edited by vvhitevvizard on 31 Jul 2020, 01:07, edited 1 time in total.
swagfag
Posts: 3976
Joined: 11 Jan 2017, 17:59

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 20:27

34. well, its not a bug. u might argue its unexpected(although if uve read about how the object hierarchy is structured, it really shouldnt be)
.OwnProps() and .OwnMethods() only enumerate the props/methods defined on that particular object. nothing more, nothing less. no, they wont walk up the prototype chain automatically, looking for additional things for u.

instance variables(as seen in a class definition) can be considered a sort of blueprint for the AHK interpreter, so it knows what to populate __Init()'s body with. thats why u dont see them when u try to enumerate the props of the class object itself - they dont actually exist at all, not anywhere! Not yet anyway at least. only when __Init() gets called(whether that happens automatically due to ur instantiating an object with randomClass.New()'s method or due to ur calling __Init() manually, is irrelevant) do the properties get defined on this instance.

but methods are defined on a separate, different object(called the prototype, accessed via randomClass.Prototype and instanceOfRandomClass.Base), so if u enumerate instanceOfRandomClass itself u get back nothing. if u enumerate instanceOfRandomClass.Base, u get the instance methods(again, not including any parent class'). why is that? because for all we care u could have previously done

Code: Select all

instanceOfRandomClass.DefineMethod('only_i_have_this_method', this => MsgBox())
and if .OwnMethods() worked the way ure proposing, it wouldnt have been able to find this method.

who knows, maybe in the future there will be .Props() and .Methods(). for now, u can write ur own such functions.
46. i thought interpreter-altering directives were off the table. a better solution is ripping the bandaid off :lol:
47. whatever
48. thats faux-command syntax for u. because theres nothing to infer a get/set context, its interpreted as a feeble attempt at method/function call.
If the return value of the function is not needed and the function name is written at the start of the line (or in other contexts which allow a statement, such as following else or a hotkey), the parentheses can be omitted.
+
Try Statement

Try
{
Statements
}

Map doesnt hash its keys(for now??). it consists of 3-way segmented array with offsets for ints, objects and strings, in that order. so logn lookup and n logn insertion
lol, leave the Array for alone, its in a good place. it doesnt matter that u think its not consistent with Map - it doesnt have to be; a Map is a Map and an Array is an Array, theyre different data structures.
in the future if more data structures are added, id want them to enumerate in a natural way that makes sense for them, not to satisfy an arbitrary constraint.
most often u want an array for its elements, not indices. i grepped 500 v1 scripts(from the time when i learned what a for-loop was lol) and came up with 318 matches of for each,
of which the most egregious...
and who knows how many more other instances there are where i simply named the variable some random shit and left it unused.
@iseahound
getpos(x:=0, y:=0, w:=0, h:=0) works fine
now that i think about it, if adding extra special operators(eg * ^ & out) would simplify the implementation/provide more robust error detection, go for it.
at the very least it would serve to better document outparam usage, whereas x:=0 may not always be relied upon(the var could have been already initialized previously, u could be inlining it to save a line, etc)
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: Updated to v2-119. [list of 47 suggestions]

30 Jul 2020, 20:37

swagfag wrote:
30 Jul 2020, 20:27
34. well, its not a bug. u might argue its unexpected(although if uve read about how the object hierarchy is structured, it really shouldnt be)
example with a simple class and an instanced object of it (just for convenience)
instance variables(as seen in a class definition) can be considered a sort of blueprint for the AHK interpreter, so it knows what to populate __Init()'s body with.
Ok. From a user point of view, I expect the non-static methods to be essentially pointers to func objects with bound this.
I recall I used the following syntax in AHK V2-103 to use fat-arrows with methods (fat-arrows weren't supported for methods back then):

Code: Select all

methodN:=()=>msgbox()
So ownmethods() output to follow (emulate at least) .pwnprops() output mode.

I tried .definemethod to dynamically add methods in order to be able to see them thru .ownmethods - it does work (see below) :D but cmon, its expected to mirror .ownprops functionality.
output 2 (it misses init method, it lists a dynamically created method):

Code: Select all

{
   "a_type":"ybt",
   "a_method":"i_say_init"
   "p":88
}
if u enumerate instanceOfRandomClass.Base, u get the instance methods(again, not including any parent class').
THIS! Thank u for ur patience to explain this. Well, for my json.dump I could add an additional loop for .base.ownmethods.

Code: Select all

s:=""
for k,v in inst_ybt.base.ownmethods()
	s.=k "|" type(v) "`n"
msgbox(a_clipboard:=s)
output 3:

Code: Select all

__Init|Func
__new|Func
init|Func
Last edited by vvhitevvizard on 30 Jul 2020, 21:31, edited 3 times in total.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests