• (nodebb)

    My money is on this being a WTF.

    But it is conceivable that it can be used to change the collection size in much the same way that StringBuilder.Length is used. I have on occasion used StringBuilder for doing things like comma separated lists where the last item must not have a comma and I can achieve it like so:

    foreach (var item in list)
    {
      sb.Append(item);
      sb.Append(", ");
    }
    
    sb.Length -= 2;
    
  • (nodebb)

    For example, the HMI's API provides its own set of collection types, in C#. We can wonder why they'd do such a thing,

    My best guess would be that it began life as a sort of proto-C++, back well before the arrival of C++98's STL, or maybe even just plain C, and was then "ported" to C-flat, and management said, "You shall port all the old code, really all of it. We'll get someone from outside to audit what you did, and if the auditors find anything that wasn't ported, there will be seventy-three kinds of Hell to pay!" So they did exactly what they were told, and left nothing of the old code out of the port, for fear that management really meant "three hundred seventy" when they said "seventy-three".

    which is certainly a WTF in itself,

    No, wondering about it is not a WTF. Well, maybe it is. Maybe the correct verb is "despair"...

  • (nodebb)

    I mean, writable length properties are not really that special, System.IO.Stream has one of those as well, as do various builders like StringBuilder.

  • (nodebb)

    A lot of people just automatically make getters and setters for all properties because they don't really know why they're supposed to have private variables.

  • (nodebb) in reply to konnichimade

    This seems most likely.

  • Alessandro Mandelli (unregistered)

    As long as .net forces you to use a property for binding a variable to a control, someone will always find a way to abuse it.

  • Joe (unregistered) in reply to Steve_The_Cynic

    That sounds plausible to me. I interned at a company that builds such machines around the turn of the century and they were using plain C at the time.

  • (nodebb) in reply to konnichimade

    A lot of people just automatically make getters and setters for all properties because they don't really know why they're supposed to have private variables.

    I think you have a wrong word in there. Try this instead:

    A lot of people just automatically make getters and setters for all properties because they don't really know that private variables are supposed to be, well, private or, at most, read-only from the outside.

  • Vera (unregistered) in reply to Jonathan Lydall

    As pointed out in the highlighted comment of 2026-02-18's article, why not do something to the effect of, "if there is more than one item in the list, add the first one to the stringbuilder, then for all the rest add a comma and the next item"? Means you don't have to remove anything at the end.

  • (nodebb) in reply to Vera

    Or add them to a List<string> and then do a Join() at the end to insert the commas.

  • (nodebb) in reply to Steve_The_Cynic

    Depends. I've seen properties used to add range-checking (or null-checking) to variables that would otherwise be public.

  • ricecake (unregistered)

    I highly doubt it, but maybe they behave like JavaScript's Array.length:

    The array object observes the length property, and automatically syncs the length value with the array's content. This means:

    • Setting length to a value smaller than the current length truncates the array — elements beyond the new length are deleted.
    • Setting any array index (a nonnegative integer smaller than 2^32) beyond the current length extends the array — the length property is increased to reflect the new highest index.
  • MRAB (unregistered) in reply to Jonathan Lydall

    That'll remove the comma and the preceding item. What happens if the list is empty?

  • Kale (unregistered)

    The count is a signed Int32. I wonder what happens if you set it negative.

  • (nodebb) in reply to Medinoc

    OK, sure, but we see all too many examples here of { get; set; } which transforms the private variable into a public variable with a slightly different name. (Like in today's contribution.

  • A Human (unregistered)

    Before I read on and found that customising the HMI meant consuming a C# api, methought the user was given access to a css file so they could do things like #logo { background-url: var("http://www.shittycorp.com/wp_uploads/2001/y2k_logo-site_new (updated) v2_NEW_NEW.gif.jpg"); }. Then I remembered there are still things that aren't an electron app.

  • Anony Mousse (unregistered)

    This is just a regular getter/setter pattern in C#. The real WTF is anyone actually using the obscurities of C#, but yes, this is valid.

  • (nodebb) in reply to Steve_The_Cynic

    And then you get ASP.NET Core Web API, whose JSON serialization only uses properties and not fields, forcing you to change all fields in your DTO to properties.

  • (nodebb) in reply to Anony Mousse

    yes, this is valid.

    You mean t is syntactically valid. In relation to the count of objects in a collection, it is not logically valid, at least not without adding some extra semantic baggage. For example, you could have the code in the setter delete obkjects from the end of the collection when it is made smaller (assuming the collection has some defined ordering) or add a default value to pad out the collection when it is made bigger.

  • my name (unregistered) in reply to Steve_The_Cynic

    as I happen to know about this (I submitted this line years ago) it seems to be a COM program which is now wrapped by .NET (Framework, of course)

Leave a comment on “The Counting Machine”

Log In or post as a guest

Replying to comment #:

« Return to Article