count vs length ( vs size)

[hopscc]

One thing that strikes me as less than optimal is that .NET has two names for methods for obtaining the number of items in something depending on the something ( how sensible is that)
Arrays and strings use .length
Collections(lists and Maps, etc) use .count

For common usage I find this tends to make a bit of a cognitive dissonance with use of Strings vs everything else
along the lines of a mind-check
'must use .count to get the size of anything except if its a String use .length'
....
'aaaaaaaaaaaarghh'

( as an aside Java does something similar though here its .length vs .size and best practices suggest use of .count for user code.
insert-smiley-for-upchuck-here ( and scream x 2 ).

Normally It would be of no import to flatten this out and add a .count to do the same thing in Strings ( and perhaps arrays though thats less of an issue ( use Lists rather than arrays)) but thats precluded since the current cobra std library already has a String extension called .count.
unaccountably ( hehehe) and unlike the most common use of .count elsewhere (like in Collections wrt .Net naming) , here it takes an arg
( bang! - brain falls over...., developer runs screaming around the room, cat takes cover)

So - checking this, the current cobra arged version uses .count(c as char) to count occurrences of a particular char in a string.
(recently changeset 2583 adds same for a substring - which is what reminded me of this purulent and cancerous lesion in cobras otherwise blemish free complexion).
Its used in a few places in the compiler each of which causes for a me a minor wtf moment when I chance across it ......
(I hate wtf moments - it causes a disturbance in my sense of oneness and general feelings of slight competence..)

The lib version is doing a count of a particular something (rather than a count of everything in the item/Object - like Collections ) so why is it not named .countOf - huh, huh, huh ??
- do you feel lucky punk - do ya ...... whoops, drifting off.

If theres any agreement to any of this I volunteer to make a patch that corrects this ( existing count-> countOf, add count alias for length , fix compiler code, add tests, sing from hilltop, dance in street, etc, etc)

(pardon the purple prose).

[Charles]

Were you drunk when you wrote that? Be honest!

Let's complete the picture by mentioning that System.Linq adds these extension methods to IEnumerable<T>:

Code: Select all

   public static int Count<TSource>(this IEnumerable<TSource> source);
   public static int Count<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate);


I find the difference between someArray.length and someList.count to be the worst because sometimes I switch between the two and then have to fix all the uses. I also prefer lists over arrays, but it's not uncommon to get an array back from the .NET stdlib. You can convert it to a list with .toList, but often doing so is unnecessary except for getting the .count method.

I was already contemplating adding .count to arrays.

Regarding String.length, it's hard for me to not think of it as "length". Python, Ruby, C# and Java all have "string lengths". It's really baked into my brain and I end up writing s.length with no effort.

I'm not coming to any decision here in this post. Just adding my thoughts for now.

[hopscc]

Not intoxicated tho perhaps a little whimsical and sleep deprived...

The main point wasn't so much forcing all (in cobra) number-of-occurrences methods to all .count or all .length but making the various differences irrelevant - the original lib methods will always be available ( wrt .Net anyway)
- its more to providing the missing ones so whatever the predireliction there's no effort involved in generating/switching between them.

Perhaps more specifically renaming the extension(s) for String.count to String.countOf to make that easily possible
either explicitly supported in the cobra RTL/stdlib or as personally desired in user (application) code.

[hopscc]

ticket:281.
includes patch.