ObjCount() or ObjLength() or ObjLen()

[just me]

That's exactly what I expected, but I don't now enough about C/C++ to do it on my own. Even though it would need a handful more lines of code to be fully implemented and some copy&paste and adjustment to be documented, what a lengthy discussion about such little thingy.

[guest3456]

So issue pull requests then. Plus, when adding new features, there is always more to consider than just the code. Design, docs, user expectations, etc. Hence the discussion

[lexikos]

Don't bother submitting a pull request for Count/Length. If I decide they should be implemented, I'll do it myself. I'm already working on the object code.

For reference

That doesn't include the object's (implicit) virtual function table pointer, or reference count (defined in ObjectBase).

[just me]

If I decide they should be implemented, I'll do it myself. I'm already working on the object code.

Oh well, if you ever decide to do it, do it first in v1.1, please. (It doesn't seem to be a 'script breaking' change).

[lexikos]

Object.Length, Object.Length() and ObjLength(Object) have been implemented in v2.0-a049.

I don't intend to implement Length or Count in v1 until I'm sure they're in v2 to stay.

Even then, Object.Length would be a 'script breaking' change, since it subtly changes the behaviour of Object[x], returning a value if x="Length" where an empty string might be expected. Technically, new built-in methods change the behaviour as well, but it's hard to imagine scripts relying on x.Length() doing nothing. Technically, adding built-in functions prevents user-defined functions with the same name from being auto-included from function libraries, but... whatever.

I'll probably be implementing Count() at some stage.

[just me]

Code: Select all

Controls :=[]
Gui, Add, Edit, w200 r5 hwndHEDT1, Edit1
Controls[HEDT1 + 0] := "Edit1"
Gui, Add, Edit, w200 r5 hwndHEDT2, Edit2
Controls[HEDT2 + 0] := "Edit2"
Gui, Add, Button, w100 hwndHBTN1, Button1
Controls[HBTN1 + 0] := "Button1"
Gui, Add, Button, x+0 yp wp hwndHBTN2, Button2
Controls[HBTN2 + 0] := "Button2"
Gui, Show, , V2 Test
MsgBox, 0, Controls.Length, % Controls.Length . "`n`n" . A_AhkVersion
GuiClose:
GuiEscape:
ExitApp

---------------------------
Controls.Length
---------------------------
2819972

2.0-a049-ea663d0
---------------------------
OK
---------------------------

IMO, MaxIndex() is the better term for a result like this.

[guest3456]

IMO, MaxIndex() is the better term for a result like this.

+1, .MaxIndex and .Count sound more intuitive i think

[lexikos]

Why would you be using it at all in that context?

[just me]

Maybe I wouldn't, but others might do because it is a built-in method/property in that context.

[guest3456]

Yeah. Actually I'm not sure what context I would ever use .Length/.MaxIndex over .Count.. (assuming .Count will do what i think it will do)

[lexikos]

"What's the length of this array?"
"The last element is element number 2819972, therefore it is 2819972 elements long"

What does it mean to ask for the "length" of an associative array? Ask a silly question, get a silly answer.

This is what I meant by context. If the keys are arbitrary handles, there's no reason to want to know the handle with the "maximum" value - it's just not relevant for handles. That the result doesn't match the name of the property shows that it isn't being used for its intended purpose. The far more common use is with arrays (indexed 1, 2, 3, etc.), and it's for that use the name was chosen.

In the majority of cases (arrays created with [] or returned by commands), Length and Count will return the same value. But for sparse arrays like [1,,3], it's generally more useful to know that the array spans from 1 to 3 than it is to know that the array has exactly two values. Length is also more useful for arrays with secondary information (like x := [1, 2, 3], x.currentIndex := 2). On the other hand, if a user goes against convention and begins the array at x[0], x.Count will make more sense than x.Length.

Maybe those usages are so rare that it should fall on the user to implement their own solution/counting method, while we keep the API at minimal size (i.e. just Count, no Length or Min/MaxIndex). I don't really think that's the case.

(Post edited 10 minutes after posting.)

Another solution I hadn't thought of until now is Object.HasKeys(Min, Max) or Object.Count([Min, Max]), returning the number of keys found within that range. I suppose that Object.Count(Key, Key) would always produce the same result as Object.HasKey(Key) (i.e. 0/false or 1/true). Making HasKey an alias for Count instead of a separate method would at least reduce the code size cost of having both.

[just me]

I'm still wondering.

Why don't you want to add a method Object.Length wich simply returns mFieldCount? How much would it increase code size? If I understand the whole discussion rigth, it would be excactly what has been asked for, and could be implemented easily.

"What's the length of this array?"

The length of this array is exactly mFieldCount.

[lexikos]

I just got through trying to explain the semantic or functional difference between Length and Count.

Returning mFieldCount is exactly what Count() would do. I already said that I'll "probably be implementing Count()".

mFieldCount is not "the length of this array" as I see it. It is the length of the internal mFields array. The difference is that the internal mFields array is indexed by an internal field index. You cannot index into an associative array using a position (such as 0..mFieldCount-1 or 1..Count).

If "length" is "the measurement or extent of something from end to end", there can be no such thing as the length of an associative array, because there are no ends. This is the definition I am using, and the one where [1,,3].Length must be 3, not 2, because the ends are 1 and 3.

[joedf]

"count" is the correct English term, and additionally it is less confusing than "length" since "counting" is directly describing the action... "Length-Ing" is not really... The right word..
Example: string.length vs array.length vs array.string.length... string.length vs array.count .... Nonsense: string.count vs array.length
I imagine using "length" would be in the purpose of resembling JavaScript.. But that isn't the goal here, no?

Ok, maybe I'm not very clear...I'm lazy + on phone
This explains what I mean pretty well : http://stackoverflow.com/a/300540/883015

[just me]

Not only JavaScript!

[HotKeyIt]

By accident I found that Object.Length() is already superfluous and can be simply reproduced with Object.Push() so I would suggest to remove it completely.

I had another idea in mind that could make Length/MaxIndex superfluous:
Since Length/MaxIndex is mostly used to Loop trough integer keys, I think it would be best to be able to split the object into separate arrays, one for integers, one for strings and one for objects.
I would suggest using Object.Clone([min,max]) to filter the array.

Code: Select all

Object.Clone(,[]) ;return an array containing all Integer keys.
Object.Clone([],"") ;return an array containing all Object keys.
Object.Clone("",) ;return an array containing all String keys.

So instead using Loop Object.Length() we would use for k,v in Object.Clone(,[])

We could also filter an array to receive only required items:

Code: Select all

Object.Clone("a","c") ;return an array containing all String keys between a and c.
Object.Clone(0,10) ;return an array containing all Integer keys between 0 and 10.

Having Object.Count() it would be then simple to find out how many relevant items the array has, e.g. Object.Clone(,[]).Count().

[guest3456]

In the majority of cases (arrays created with [] or returned by commands), Length and Count will return the same value. But for sparse arrays like [1,,3], it's generally more useful to know that the array spans from 1 to 3 than it is to know that the array has exactly two values.

Thanks, that explains the difference. I'm assuming those are keys and not values in the brackets, ie:

Code: Select all

array := []
array[1] := "val1"
array[3] := "val3"

;// so   .Length()=3   and   .Count()=2     ?

Still not sure why I would ever want to loop over 3 items though. Perhaps I would want to know that the ".MaxIndex" was 3 for some reason.

In this case below, is it still .Length() = 3 (ie, the 'distance' from 2 to 4) and .Count() = 2 ? Because if so, then that would explain the difference between "Length" and "MaxIndex" as well

Code: Select all

array := []
array[2] := "val2"
array[4] := "val4"

[joedf]

+1 HotKeyIt's idea
@justme lol, true... but mainly what I wanted to say is in the link

guest3456 has point, .length could mean the Max int key but Then we do have .MaxIndex() there but there could also be a .size() and .count() ... It would be cool have these features, but then I don't know if these would be necessary, and would contribute to confusion etc... :s

[lexikos]

By accident I found that Object.Length() is already superfluous and can be simply reproduced with Object.Push() so I would suggest to remove it completely.

Loop % array.Push()? No thanks. We do not want to make things more obscure and confusing.

Since Length/MaxIndex is mostly used to Loop trough integer keys, I think it would be best to be able to split the object into separate arrays, one for integers, one for strings and one for objects.

I will not clone an array just to determine its length. I would also avoid cloning an array to enumerate it, but not as fervently. (Returning an array of keys for enumeration, for instance, is something I might've done in some other language.)

I would suggest using Object.Clone([min,max]) to filter the array.

I thought about that when I added Clone, but it didn't seem worth the added code size. There would also be no natural way to specify object keys (the concept of range doesn't really apply). Clone([],"") is not natural/intuitive.

So instead using Loop Object.Length() we would use for k,v in Object.Clone(,[])

So instead of just looping, we have to create an empty array, then clone our array, then create an enumerator object and call its Next method once for each iteration. No thank you.

I'm assuming those are keys and not values in the brackets,

Correct. I should have written something like ["val1",,"val3"] to be clear.

Still not sure why I would ever want to loop over 3 items though.

You might loop over an array even if you know its contents, just to reduce code repetition. Obviously the concept isn't restricted to array literals or arrays you know the contents of in advance. It's just a simple example to convey the general idea.

In this case below, is it still .Length() = 3 (ie, the 'distance' from 2 to 4) and .Count() = 2 ?

That wouldn't work well with sparse arrays where index 1 is missing, or Loop array.Length ... array[A_Index]. Length assumes that all arrays start at index 1, as is the convention in AutoHotkey.

Because if so, then that would explain the difference between "Length" and "MaxIndex" as well

The difference is that if there are no indices, there is no MaxIndex (it is empty, not 0).

[toralf]

I would suggest using Object.Clone([min,max]) to filter the array.

I thought about that when I added Clone, but it didn't seem worth the added code size. There would also be no natural way to specify object keys (the concept of range doesn't really apply). Clone([],"") is not natural/intuitive.

I actually like the idea to "filter" an array. Just today I coded a function, that worked on a portion of an array (because new key/values were added later).

Code: Select all

For i,File in FileInfo {
  If (i < StartID)
    Continue
  ...
}

Basically I looped through the whole array and skipt all key/values until I got to the point were the work could start.

The alternative would have been

Code: Select all

Loop % FileInfo.MaxIndex() - StartID {
  File := FileInfo[A_Index + StartID]
  ...
}

Not very elegant either, but at least only looping over the key/values in question.