AutoHotkey Community

nnnik wrote: ↑

24 Jan 2019, 04:15

Maybe you just have very limited experience in programming. At the very least that would explain your reaction.
Using an object as key is nothing amazing and is done in many languages in different ways.

I think the issue is my poor English. I might expressed it in a wrong way so u don't understand me. We have a string or integer index as a key name, we have some value (pointer to an object) assigned to a key. object can contain objects, but its stored in the right field (value). left field of an object is its name (key). In low-level languages left "string" key name might be a an address, index, offset, etc. In AHK or lets say Python it is a string name.

Maybe you just have very limited experience in programming.

I don't think I had a limited experience in programming. But it was in the past, DOS times, when I was writing drivers mainly in Assembly. Yet I perfunctorily used almost every language those times - C, Pascal, Fortran, Basic, "РАПИРА" (Russian one). Last 10-15 years I do only casual stuff with JavaScript, Python and AHK.

AHK is an interpreted language. The Associative Object in AHK performs actions similar to a map - It maps one value to another.
Thats nothing amazing or groundbreaking. In AHK there is no good reason to limit yourself like you would in Assemblies or Cs linear arrays.
I think even C++ has a datatype that can do what we are doing here - at the very least I know that there are libraries for this.
Python certainly have a way to do that - the objects are probably just seperate types.
In Java it's called a Map - the Map maps Objects from one datatype to another.

I can imagine that this is confusing for you - but your reaction (as in this form of aggressive rejection) does not make you look good.

Helgef wrote: ↑

24 Jan 2019, 04:03

Code: Select all

for k, v in { func('msgbox') : 'hello world' }	
	%k%(v)

Yes. Internally we saw that key name's type may be a reference to an object. yet I don't see any advantages of it. Object reference might be stored in the right field (value) with all its properties ("hello world" string, etc) inside that referenced object.

Look at Python - left side in the assignment is just a string (a unique name), right side is always an object (strings, numbers, lists, dictionaries, functions, whatever). Internally Python might store hashes instead of strings for names.

but your reaction (as in this form of aggressive rejection) does not make you look good.

I'm really sorry - I didn't mean to sound aggressive. When I type fast I forget about manners it seems.

In Java it's called a Map - the Map maps Objects from one datatype to another.

I'm not familiar with Java, but according to Map description I can imagine it as a collection. With unique keys (hashes) to the left and values to the right (mapped value).

What I meant is left side is a key and can be of 1 type only ("string" or hash/address/index - integer, doesn't matter - it just has to be unique for the current namespace/virtual address space/indexed table) and right side is a value (mapping to another object/data type, pointer to an object, literal string, integer, 128-bit MMX register, bit array, etc).

nnnik wrote: ↑

24 Jan 2019, 04:42

AHK is an interpreted language. The Associative Object in AHK performs actions similar to a map - It maps one value to another.

Isn't it consisting of pairs key:value for the user script's level logic? Methods of the particular object might (or might not) do enumeration, intercept references to some keys thus effectively doing mapping, etc.
I wonder, whats the desperate need to use ["obj_key"]:["obj_val"] syntax instead of "obj_key":["obj_val"].
"Occam's razor" problem-solving principle states that simpler solutions r more likely to be correct than complex ones.

And what exactly is a key? Not a value?
A key is any value that takes up the role of a key in a key-value pair.
Do I have to make up examples for you where it could be useful?

I wonder, whats the desperate need to use ["obj_key"]:["obj_val"] syntax instead of "obj_key":["obj_val"].

This has nothing to do with syntax. ["obj_key"] is an array containing one string, "obj_key". That array is associated with the array containing the string "obj_val", it is not a syntax version of "obj_key":["obj_val"], where the string "obj_key" is associated with an array containing the string "obj_val".

nnnik wrote: ↑

24 Jan 2019, 06:21

And what exactly is a key? Not a value?
A key is any value that takes up the role of a key in a key-value pair.

a key is a unique identifier containing a value.

And said unique identifier value cannot be any object?

Examples:
As a guaranteed unique value: As a storage for information about objects: ...
You name it

nnnik wrote: ↑

24 Jan 2019, 06:37

And said unique identifier value cannot be any object?

Helgef wrote: ↑

24 Jan 2019, 06:22

"obj_val", it is not a syntax version of "obj_key":["obj_val"]

Yes result is not the same: left side is either object or literal string.

And that's what makes me questioning - if we wanted to add array's reference to another object, there r more plain and clear ways of doing that with Push() etc

if (someParameter.hasKey(this.SPECIAL_UNIQUE_SLOT)) {

and what prevents u from using regular string key:value paradigm here? U store unique id as a key name and for value u can have an object of any complexity and any depth of nesting. U got some complex object? U create a hash or any other UID for referencing this object. For performance it boils down to using either just addresses within virtual address space (pointers) or using hashes/indexes.

nnnik wrote: ↑

24 Jan 2019, 06:37

And said unique identifier value cannot be any object?

key name can be informative and adjusted to ease algorithmic search/indexing.
At some point u have no other way as to store address of ur object or invent some other indexing system to reference it later. Key name is that simple unique id which can be represented as a string or integer. Its a name of container.

Strings are not guaranteed to be unique. Objects are guaranteed to be UNIQUE.
If you wanted to you could create a class that handles creating unique ids and adding a represantative name.
If your indexing system does not cover objects in keys it's simply not fit for AHK.

and what prevents u from using regular string key:value paradigm here? U store unique id as a key name and for value u can have an object of any complexity and any depth of nesting. U got some complex object? U create a hash or any other UID for referencing this object. For performance it boils down to using either just addresses within virtual address space (pointers) or using hashes/indexes.

As you dictated before: The easiest solution is most likely the correct one. And here storing the object as key is the correct solution.
All the methods you mentioned are potentially problematic and can cause issues in specific cases.
I dont know why you are fighting this feature - it makes me feel like Im wasting my time talking to you.

nnnik wrote: ↑

24 Jan 2019, 07:39

Strings are not guaranteed to be unique. Objects are guaranteed to be UNIQUE.

Not objects themselves. their pointers. Effectively simple integers. What stops u from using integer as a key name?
Strings may be unique for particular namespace. Within a class one might have full control over created key names.
Also unique strings may be created using timestamps and other techniques.

nnnik wrote: ↑

24 Jan 2019, 07:39

I dont know why you are fighting this feature - it makes me feel like Im wasting my time talking to you.

No this one is of no special importance to me.
Yet serious revamp would require to reassess usefulness of things like this one instead of advocating it - ofc u can find a way of using it - but u can find a way around and use regular key:value paradigm and that's what Occam's razor meant. I just pick such things from force of habit; I used to optimize other ppl projects for quite a while.

Not objects themselves. their pointers. Effectively simple integers. What stops u from using integer as a key name?

Ofc you can store an object's address as an integer key, it is very inconvenient though, since you have to call object / objaddref / objrelease as appropriate.

Strings may be unique for particular namespace

String keys aren't even case sensitive.

Once again, I am lost, I don't know what the point of this thread is anymore.

Cheers.

String keys aren't even case sensitive.

generate names w.o letters. or with reduced set (e.g. only in lower case). how many different symbols u need to create a unique hash string?

Ofc you can store an object's address as an integer key, it is very inconvenient though, since you have to call object / objaddref / objrelease as appropriate.

I would store an object's reference in the value field effectively creating/removing reference to it (instead of manually invoking objaddref / objrelease).

This pointless, if you want to associate an object with some value, what we got is the most natural and convenient way, without any downside.