AutoHotkey Community

I dont think that there are that many use cases for a standard programmer that would warrant having these functions build in.
However we could always add them later if experience shows that they are needed.

- Well, a core of 'built-in' comparison functions could appear in the documentation, so that at least there's some standardisation.
- The Sort function in effect already has some 'built-in' comparison functions (via its options).

Yeah I would also appreciate it if the sort function could be changed similar to this function:
https://autohotkey.com/boards/viewtopic.php?f=6&t=46260

Mostly, when I feel I need this functionality, I also feel like completely rewriting the code I'm working on... Anyways, I will add to the brainstorming, where fieldIndex is the (1-based) index of the found key/value pair. Naturally, we would have a method to retrieve the key/value pair at some index, Together with a count([keyType]) method and changing haskey() to return fieldIndex as well, we would have better support to write custom enumerators and we could avoid redundant look ups (maybe also assign(index, newValue)). My suggestion somewhat implies that some parts of the implementation would need to be documented, i.e., guaranteed. For example, a custom enumerator enumerating over, eg, only object keys, would rely on them being stored together (in a range of field indices after the last integer key index).

I guess case could be caseOrCompareFunction, although, if using a custom compare function, probably most of the speed advantage (of having a built in method) is lost, so might as well use a custom function (for loop). But, I like the convenience it implies I guess.

Cheers .

I think thats a good suggestion in general however that creates those ugly
while index := function( index )
;do something with index or access index in some way. that C++ programmers like for reasons I can't even begin to understand.
Also each obj.hasValue and each obj.field is also a lookup so it will do a lot but it won't decrease lookups.
It also once again won't fit 1-line logic that has become increasingly important.

While the rest of your post is a nice suggestion I don't quite know if it fits the current topic.
If you could give an extended reasoning as to why you want to have it exactly in this way that would be nice.

Hello nnnik, I was going to make an edit, saying one would need to use the corresponding objxxx functions to actually save look ups.

The idea isn't really mature or something I greatly desire, but in general, the more control/access we get, the more things we can do. I think it also gives use to a count method which people have been asking for, currently, such a method has no use.

Probably one of the more standard suggestions made in this thread is more suitable.

Cheers.

If you are specifying a function to apply to each value to determine if it should be included, Needle is redundant, and "has value" may become a misnomer depending on what the function contains. See for example Array.prototype.filter().

Yay for JS Array.filter! Super useful for functional programming.

lexikos wrote:If you are specifying a function to apply to each value to determine if it should be included, Needle is redundant, and "has value" may become a misnomer depending on what the function contains. See for example Array.prototype.filter().

Yes but noone suggested to always define a comparison function. And as I said before the comparison function that could also be used in Sort and many other functions could be used here to if we define a needle.
I also think that the default case will be the most common case so in the majority of cases defining a comparison func won't be neccessary.
Once again defining a comparison func might give us the ability to further enhance the speed of .findValue if it gets accessed a lot. ( to be precise by doing O(n log n) precalculations we can build a search tree with O(log n) complexity ).
The other syntax would not make this possible - though thats only possible if we make the user define a comparison func.

+1 for Javascript Array.filter

Alternatively if you want a needle, maybe return an iteration object like in Rust or define your own iteration object like in Python?

The OP mentions:
Object.HasValue(Value [, CaseOrTypeSensitive, ByRef Key])
An equivalent extension of HasKey would be useful:
Object.HasKey(Value [, CaseOrTypeSensitive, ByRef Key])
This would be good for a case-sensitive spelling list. So, you could input the word in any case, if the key was title case this would indicate that a lower case spelling was incorrect.

nnnik wrote:Once again defining a comparison func might give us the ability to further enhance the speed of .findValue if it gets accessed a lot.

A user-defined comparison function would be much slower than any built-in comparisons.

Built-in standard comparison functions for common cases could help there. ( By built-in I dont mean build into the function but rather build into AutoHotkey )
Also I think that those special cases with comparison functions are rare.
In 99% of the cases you just want to find a specific value.

Somehow the word premature optimisation pops into my mind for some reason - although Im not sure if it applies here.

AutoHotkey v1 implementation:

That will work in v2 too stealzy

Cheers.

I haven't followed the discussion, but I think that has sounds like it expects "yes" or "no" answer, therefore true/false. In addition to that, You could make find, which returns array of key names containing the value. Unsure if they can be merged into one, because key can be 0 which equals false:

SirRFI wrote:I haven't followed the discussion...
...Unsure if they can be merged into one, because key can be 0

I think, you should read at least last message with code.
All keys return in array, so even if it's found only one match value with key 0, function return array [ 0 ], which equals true, not false.

Btw, [ "" ] also equal true, even empty array [ ], {} not equal false.