AutoHotkey Community

Actually it, removing the key when setting with empty string, is the one currently bothering me in practice.
Right with AHK as AHK has no concept of undefined, and I realized that creating new key would make meta-functionality useless.

A summary of what I plan to do next (mostly things that have been "discussed" already):

• Make x.y[z] equivalent to x["y",z]; mostly for objects which rely entirely on meta-functions, such as COMo/COM_L. Where the previous behaviour is required, (x.y)[z] may be used. (Edit: A better way to disambiguate might be: x.y.[z].)
• Allow dynamically-named method calls (with syntax sugar): obj[name-expression](params) and/or obj.%var%(params).
• Allow meta-functions to entirely override same-named keys in the base object; i.e. give meta-functions precedence.
• Replace Object._Insert, _Remove, etc. with ObjInsert, ObjRemove, etc. - these will no longer be pre-defined ._Methods() of all objects.
• Possibly replace _SetCapacity/_GetCapacity with just ObjSetCapacity, trying to keep it consistent with VarSetCapacity. For instance, ObjSetCapacity(obj) might return the current capacity and ObjSetCapacity(obj,-1) might shrink to fit its current contents.
• Key/value enumeration functions. For instance:
  
  Code:
  KeyWasFound := ObjXxxx(obj, key[, value])
  Xxxx may be First, Last, Next or Prev. Basic enumeration code might look like this:
  
  Code:
  if ObjFirst(obj, k, v)
      Loop {
          ... do stuff with k(ey) and/or v(alue) ...
          if !ObjNext(obj, k, v)
              break
      }
  
  If something like for k, v in obj is ever implemented, it might rely on these functions by default.
  ObjFirst/Last should provide some way to retrieve the first/last key of a given type, possibly replacing _MinIndex/_MaxIndex. Any suggestions?

I'll start coding these soon (probably in the order listed), so speak now or... think of something less clichéd.

That looks very cool, many thanks




I would vote to not differentiate between types to keep it simple, it should just enumerate trough all keys I think.
You could always check the type of the key using "If var is type" or "IsObject()" if necessary.

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

The code produces a compile error.

That was my intention, which is why I mentioned only First/Last and not Next/Prev. I just think that having both First/Last and MinIndex/MaxIndex seems redundant and could cause confusion. I'll probably add another optional parameter after the value parameter.
Yes, but then you would need to enumerate/loop and evaluate keys even though the implementation allows the first or last key of a given type to be retrieved directly, without any searching.

What types do you think to support?
- integer, string, object ,float, xdigit, alpha, or even more?

Will there still be an option to enumerate trough all keys in one go?

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

xdigit and alpha are not types; they are string patterns.

I already said it "was my intention" for those functions to enumerate through all keys, and that I would "probably add another optional parameter" for the type of key. What do you think will happen if that optional parameter is omitted?

Okay, I see, that would be great.

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

Lexikos,
Thanks for your great Ahk_L version, but It seems like there is limit of a number of 99 gui that can be used in a script.
The first code below doesn't work while the second does.
Are you aware of this limitation

It is a well known and documented limitation of the Gui command in any AutoHotkey version.

sorry for my ignorance
i guest i might have missed that
thanks

Dear Sir Lexikos,
I would highly appreciate you could implement a loop parsing of an expression to be able to do something like
Instead 0f
And if not possible, is there another alternative to this?

Are you gonna also allow this?

Sean,
I guess you meant to write [z] rather than (z). I meant x.y[z] in both contexts: v := x.y[z] and x.y[z] := v. (So yes, the latter will be equivalent to x["y",z] := v.) Edit: That said, my earlier statement was a little inaccurate/ambiguous - w.x.y[z] will be equivalent to (w.x)["y",z] and not w["x","y",z]. (If there is no use of __Get, they'll all behave the same anyway.)

wiseley,
I'll consider it, but it probably won't happen any time soon if at all. I'm not sure why you would want "another alternative", and I don't think there is one; assigning the input to a variable is necessary.

FYI, I think that the "% " shouldn't be necessary since there is no ambiguity.

No, I meant (z). Currently x.y(z) := v is a meaningless/incorrect expression, so, how about giving it a meaning?

Restricting the discussion to COM_L, I suppose a lot of users, especially from VBScripts, will attempt the syntax (z) than [z], and the above is the only one not working in COM_L (Get can be replaced with Call as COM_L doesn't differentiate the two). So, if all are implemented, the following two will do the identical jobs with current COM_L, so, an user can choose either () or [].