Map shorthand

Discuss the future of the AutoHotkey language
User avatar
TheArkive
Posts: 623
Joined: 05 Aug 2016, 08:06
GitHub: TheArkive

Re: Map shorthand

Post by TheArkive » 24 Apr 2021, 02:03

Map(key, value, key2, value2, ...) works for me.

One down side is that if you want case insensitive keys then you must:

Code: Select all

obj := Map()
obj.CaseSense := false
obj[key] := value
obj[key2] := value2
...
SInce Map() is now a class, it should be extendable... I'll see what I can come up with...

lexikos
Posts: 7583
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Map shorthand

Post by lexikos » 24 Apr 2021, 02:52

You "must" assign the values individually?

It's trivial to write a function or class that uses the same syntax as Map, with case-insensitivity and a different name.

At worst, make the function variadic and use a loop.

Code: Select all

Mip(p*) {
    m := Map()
    m.CaseSense := false
    loop p.Length//2
        m[p[A_Index*2-1]] := p[A_Index*2]
    return m
}

MsgBox Mip('A', 'b')['a'] ; b
Or you could just use Set.

Code: Select all

Mip(p*) {
    m := Map()
    m.CaseSense := false
    return m.Set(p*)
}

Code: Select all

Mip(p*) => (m := Map(), m.CaseSense := false, m.Set(p*))

MsgBox Mip('A', 'b')['a'] ; b
Or you can set CaseSense during initialization (which is before the items are added by the constructor).

Code: Select all

class Mip extends Map {
    CaseSense := false
}
MsgBox Mip('A', 'b')['a'] ; b
__New is an alias of Set, and can be used in the same manner; but don't.

Note the post dates prior to iseahound's post.

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

Re: Map shorthand

Post by vvhitevvizard » 24 Apr 2021, 05:35

lexikos wrote:
24 Apr 2021, 02:52
m.CaseSense := false
BTW, I suppose CaseSense's "On"/"Off" needs to be addressed:
https://lexikos.github.io/v2/docs/objects/Map.htm#Set
Because u unified it and removed literal strings for such boolean switches overall.

User avatar
TheArkive
Posts: 623
Joined: 05 Aug 2016, 08:06
GitHub: TheArkive

Re: Map shorthand

Post by TheArkive » 24 Apr 2021, 05:59

Wow, i was way off. I need to remember to keep going back to read the docs... :facepalm:

I had forgotten about Map.Set().

lexikos
Posts: 7583
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Map shorthand

Post by lexikos » 24 Apr 2021, 18:25

vvhitevvizard wrote:
24 Apr 2021, 05:35
BTW, I suppose CaseSense's "On"/"Off" needs to be addressed ... Because u unified it and removed literal strings for such boolean switches overall.
Nope.

CaseSense is not boolean; it returns one of three string values:
"On"
"Off"
"Locale"

These are the same values accepted by StrReplace, StrCompare, InStr, IsAlpha, IsAlnum, IsUpper and IsLower.

Strings are used because they are clearer, especially for "Locale" and "Logical" (which is accepted by StrCompare).

Integer pseudo-boolean values are not preferred because if 0 is not case sensitive, if CaseSense would logically be used to check for case-sensitivity, but would actually only be checking if CaseSense is not the non-locale case-insensitive mode. In other words, it would mistake "Locale" as case-sensitive.

Reversing the meaning of the property and various parameters would permit if CaseInsensitive where CaseInsensitive could be true or 2 or "Locale", but it doesn't seem worthwhile.

Hotkey, Hotstring, SetCapsLockState and similar functions also accept "On" and "Off". Hotkey does not accept 1 or 0 in their place.

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

Re: Map shorthand

Post by vvhitevvizard » 25 Apr 2021, 07:35

lexikos wrote:
24 Apr 2021, 18:25
CaseSense is not boolean; it returns one of three string values:
"On"
"Off"
"Locale"
I'm aware it has the 3rd option thus making it not suitable for binary logic.
Just a proposition, for CaseSense, it might be just another boolean property added, e.g. m.CaseSense true/false for sensitive/insensitive and m.Locale true/false as an additional mode for case insensitivity. And the very same logic of splitting a literal string value into 2 boolean switches for other mixed switches remaining (e.g. Critical ["On"|"Off"|Numeric]). That would unify the overall pattern, improve performance (pure numbers vs strings) and dramatically alleviate filling these switches programmatically.

lexikos
Posts: 7583
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Map shorthand

Post by lexikos » 25 Apr 2021, 19:55

There are exactly three possible modes of comparison, not two separate binary options. "Locale" and "case-sensitive" are mutually exclusive, and the setting can't be changed once you add any items. I see no benefit to having two separate properties for it, only drawbacks.
That would unify the overall pattern,
Would you change the several functions I mentioned as well, splitting their CaseSense parameter into two parameters? If not, I suppose that's the opposite of unification. Even if things are "more unified", specifically how is it helpful?
and dramatically alleviate filling these switches programmatically.
How so? Perhaps you can demonstrate.

Critical/A_IsCritical already accepts and returns a pure integer, and there's no need to save or restore two separate settings.

As for performance, I don't believe this is a real concern in general. For properties specifically, assigning one string property is most likely faster than assigning two integer properties.

iseahound
Posts: 713
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Map shorthand

Post by iseahound » 25 Apr 2021, 21:27

Has there been any further consideration of named parameters? I read in your other post that there would be no further big changes to the language.

Currently unpacking only extends to keys:

Code: Select all

a := Map("a", "AAPL", "b", "BA", "c", "CHWY")

fn(a*)

fn(p*) {
   for i, v in p
      MsgBox i ", " v
}
I was thinking of behavior similar to **kwargs in Python.

iseahound
Posts: 713
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Map shorthand

Post by iseahound » 07 Jun 2021, 11:22

I think that it needs to be decided if {} will refer exclusively to AutoHotkey objects or maps. I don't really have a preference, but whatever the choice is will likely stick. As finc's post says, I do find myself using object properties as a return value instead of a map. Given expectations of JSON objects and python dicts, it may be adventurous to do otherwise.


Upon thinking about it, I believe buliasz 1st suggestion to be the most preferable.

Code: Select all

map := [
	"key1" : "value1",
	"key2" : "value2",
	...
]
Part of the reason why is because both arrays and maps are ordered so maintaining the same syntax feels like a natural extension of the other.

If linked lists/ unordered dictionaries, hash tables (also known as python sets) ever get implemented they should use an alternative syntax.

lexikos
Posts: 7583
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Map shorthand

Post by lexikos » 11 Jun 2021, 20:09

1. It was decided before this topic even started. :roll:
2. That syntax was suggested by Helgef in the second post of this topic, and I already brought up one problem with it.
3. Your reasoning that both arrays and maps are ordered is flawed. An ordered map would retain the order in which the key-value pairs are specified, like an Array. That is not how Map works.

iseahound
Posts: 713
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Map shorthand

Post by iseahound » 12 Jun 2021, 10:48

3. Sorry, I meant sorted. Currently Maps and Arrays are auto sorted.
2. Is map := [:] unreasonable?
Square brackets are the least offensive choice, and perhaps that may not be reason enough.

lexikos
Posts: 7583
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Map shorthand

Post by lexikos » 12 Jun 2021, 17:26

Arrays are not auto sorted. The order of items in an Array are retained. They are stored in that exact order, and accessed by calculating the offset based on the index, not by searching. The order of items in a Map are not retained. Maps and Arrays are not equivalent in either regard.

I already posted the idea of [:] last year. There's no dedicated syntax for Map not because I couldn't decide on syntax, but because I decided it was unnecessary.

Post Reply

Return to “AutoHotkey v2 Development”