AutoHotkey Community

Lexikos, you are geniuos, thank you so much for new features.

Object feature is bombastic

I like A ~=B, hope it will be kept in future

Does it mean LowLevel is fully functionally again


Edit:
Looks like strings and digits are threated differently:


Is there possibly a way to enumerate trough items in the object?
Do you possibly intend to change AutoHotkey commands to support objects or will there be internal functions to do that or should we start to write functions (where possible)?


It looks like it is not possible to use an object as variable and the object gets inaccessible if done so?
I think this should be noted in helpfile, so it would be clever to use # _ @ $ in object variables.

Here the object seems to be broken

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Lexikos, legendary release! I will have to study/experiment before I can give some intelligible feedback on the object implementation. Hopefully I won't spontaneously feel like re-writing everything I've ever written in AHK.

Do you have any thoughts/plans to implement a means to retrieve any meaningful output, such as FoundPos, or any captured subpatterns? If not, then I suppose I will probably tend to stick to the regexmatch function call. Although, it wouldn't hurt to leave in place since that is a standard syntax for RE (at least in perl).

_________________
.o0[ corey ]0o.

~= returns the foundpos:

Most or all of the LowLevel functions which work with v1.0.48 should work. I've also updated DebugBif() for L31 compatibility.
That is due to pre-existing AutoHotkey behaviour - quoted literals are considered purely non-numeric. Why quote a numeric literal if you want it to be treated as a number rather than a string?
Not really (yet). However, for "conventional" arrays, _MinIndex and _MaxIndex can be used:

I do not intend to update commands; though they could accept objects via variables, it might seem inconsistent since objects aren't supported by the traditional, non-expression syntax. Changing commands to use objects unconditionally would reduce backward-compatibility, remove some useful functionality and in some cases reduce performance. "Overloading" them to use an object if present might be too obscure; by contrast, having a distinct function() would make the difference in behaviour obvious.

I was thinking that RegExMatch could output its results to an object if one is present in UnquotedOutputVar. (It would be less obscure than for StringSplit since in-line assignment is possible: RegExMatch(A,B,C:=Object()).) I may also implement SplitStr() as a function. For now they can be written as script functions (with a little difficulty in the case of RegExMatch).

Can you think of any commands that would really benefit from it other than StringSplit?
I'm not in favour of re-using a parsing loop since it doesn't really make sense.
I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. An object is merely a value which may be stored in a variable. Would you expect a variable to keep its previous string contents after you assign it a number?
I think it is already implied by the following:

I disagree. IMO, a variable's name should reflect it's meaning or usage, which should imply the type of value it holds. If you don't know what a variable is used for, you don't need to know what type of value it contains. Additionally, I think those symbols don't really imply "object". (If you wish to prefix variables in this way I have no objections, but I will not recommend it.)

Since this works it is not a problem



StringSplit and RegExMatch looks to be the only commands where we would really benefit from.

I thought this could enumerate trough the objects and A_LoopField would contain nextkey.

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

If..in/contains ?

Very interesting release!

Thats a long waited feature to me. Hope Chris implements it in mainstream Ahk. Please don`t overlaod it. The simplicity and performance are main reason to use it. I love it. Not tested yet, hope ErrorLevel will be not changed also. +10/10

Here are some thoughts/wishes about that:

What about subpatterns here? Are they lost? I suggest that it should. Or they could be saved in variables 1 to xxx... very bad.

But at named subpatterns:

may could create variable Year directly.

Example:



Lexikos, I like you very much. Really.

-------------------
EDIT: my bad all ok

how can i implement h_icon in:


i searched the forums but there is no way i know off to get the icon(exe)path,and nr from h_icon

is it posible to support h_icon in the menu?
or i keep searching for a while for a convertion.

Perhaps you should clarify that these object based arrays are still just associative arrays.
I am still waiting for syntactic sugar for numput and numget, ie. real, fixed, in memory contiguous arrays, that can be referenced using index arithmetic and without a binary search, and that allow binary values.
I wonder how hard it would be to modify your implementation to create more c like arrays.

In the meantime, I am sure these arrays will still be useful.
Thank you, Lexikos.

+1

Or A_LastMatch maybe?


Edit: Or

So basically, make A~=B equivalent to RegExMatch(A, B, A_LastMatch:=Object())

Thanks for the input.

I got that. My point was that since it doesn't do any parsing, it would not make sense to use "Loop, Parse".

I think that your examples are inconsistent with the current semantics of If..in/contains, and that any implementation supporting objects will probably be ambiguous and not necessarily intuitive. However, I recognize that the functionality could be very useful so I'll consider implementing less ambiguous methods - e.g. obj._HasValue(v) or obj._KeyOfValue(v). The latter seems more useful. _HasValue(v) would be equivalent to _KeyOfValue(v)!="", except that "" is actually a valid key.

Perhaps it should be considered further if/when in/contains become supported in expressions, since they necessarily won't be consistent with the current syntax.
That would be equivalent to Obj.x!="" since assigning an empty string removes the item and its key. That is, unless "If in" (or whatever) bypasses the meta-mechanism; I'm not sure whether that would be intuitive.

I think it is simpler than you realise: When I said A ~= B is equivalent to RegExMatch(A, B), I meant it precisely, not figuratively. It is nothing more than syntax sugar which is processed entirely at load-time. The two should not behave or perform any differently.

I'm reluctant to changes its functionality, partly because I think an operator's purpose and effect should be very clear (i.e. with no hidden side-effects, though ~= does set ErrorLevel) but moreso because I think its usefulness is too limited to justify spending much time on it. In fact, I spent approximately two minutes coding ~=, having already done something similar (translation of x[y]:=z to ObjSet(x,y,z)).
That's an interesting suggestion, but I think it contradicts your earlier points about simplicity and not overloading ~=.

It is not currently possibly. I had considered supporting it indirectly by extending LoadPicture (which is used by various commands) to accept an icon or bitmap handle. Since there didn't seem to be much demand for it, it "slipped off the list". I'll reconsider adding it in a future revision. Until then, you may use MI.ahk, which can accept either an icon handle (HICON) or filename. AHKControl uses it for a purpose similar to what you've shown.

I would think it should be clear enough from the title "Associative Arrays", the (hopefully) consistent references to "keys" rather than "indices" and the fact that "[integer] keys do not need to be contiguous". Anyway, why do you say "still just associative arrays"; why should they be anything else?
It shouldn't be too difficult; just extend the IObject interface or ObjectBase class.

I'd like to implement C-like user-defined structs, but I'm not confident that built-in functionality would be justified. Implementing it in script would be feasible, perhaps even easier (though less efficient) than in C++.
Objects are binary values, and may also be written around "proper" binary arrays (i.e. with GlobalAlloc).

String fields in an object expand in the same way that a variable expands - when necessary, to avoid some repeated reallocations as strings of different lengths are assigned. (I realise I should try to work this into the documentation.) They could also be used to store binary data in the same way as variables, by extending _SetCapacity and adding _GetAddress. Actually, there's already code for it in L31, but it's commented out. It seemed to me that at the cost of added code and documentation size, its only benefit over simply storing a pointer returned by DllCall was that no extra code was needed to automatically manage the memory.

Oh! Now that I think of it, an important feature slipped my mind while I was writing the documentation. After the last reference to an object is released, the __Delete meta-function is invoked. If the object has no references after the function returns, it is deleted.


That's an example of a hidden side-effect, which I'd prefer to avoid. Also, typing RegExMatch out in full allows for much shorter or more meaningful variable names.

I hope you didn't take it personally. My thoughts are usually focused on the nitty-gritty of implementation rather than the larger picture, so I tend not to do much formal "analysis and design." I'm also a natural loner. (I'd like to have replied sooner, but I was at a loss for words.)

I am dissapointed in that. The "suggestion" about named subpatterns was just an idea to discuss, not a direct wish. ErrorLevel should not be changed, because it is not a function call. You are right about sideeffects, no sideeffect should be existing with operators.
If it is a simple "macro replace", then the usefullness is not that great I was thinking.

First off, I'd like to say: Amazing Release! Thank you for your work. I had been highly anticipating this implementation.

Now I was wondering (please forgive me if this is a ignorant question), is it at all possible (or will it be possible) to create a COM object - or use this syntax with a COM object? Something like:
To the best of my understanding this creates two separate objects, and would dereference the AHK object - therefore destroying it.

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

You'll have to rewrite the whole COM.ahk to support objects for that or create a wrapper
Demo (Edit: See COMo - Object oriented COM for latest version):


This works too:

Or

Lex, Any reason why @, # are not allowed in dotted identifiers? I was going to use ShellApp.@Windows.Count but that doesn't work. An alternative is ShellApp["@Windows"] but then I can't use the same character for function calls.. because SA["@Item"](..) calls __Get for @Item while SA.Item(..) calls __Call

Edit: Updated with Lexikos' suggesions below (COM_VT and static base).

Understood. I discussed, did I not?
I agree. I'll consider changing it, though it would require more time than I'd like.
My thought from the beginning has been that it isn't very useful; removing the ErrorLevel side-effect won't change that.
I figured it was best to limit the character set initially and expand it if absolutely necessary, rather than breaking scripts as I've had to do for variable names.
For now you may use ObjCall.
I haven't had time to implement method-calls with []; I plan to in a future revision.
Note that it creates a new base object each time. I hope that in a future revision, it will be a simple matter of prepending "static" (with no need for "if !COBase ... COBase :=").
I'd understand if you find it easier to follow this way, but note that the shorter method should also be marginally faster:

IIRC, the global variable COM_VT should be 9 if COM_Invoke's return value is an object. Using that, wrapping objects can be automatic, and reliable when a function may or may not return an object.