Cobra Forums

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).

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.

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.

ticket:281.
includes patch.