C#'s biggest mistake

When C# was a teenager it was into drugs, and although it went to rehab, this set back its college education for 10 years. By that time, it was harder to get a job, because all of the tech companies were looking for younger people.

That was C#'s greatest mistake.

@Bass:LINQ-to-Objects. Some people seem to thing it looks fancy in code (I guess?), but I don't think it makes the code any clearer then a simple foreach loop (which tends to be faster anyway). See above also.

I have to say I think code is eminently more readable when you have a .Any(a=>) or .All(a=>) or .Skip(a=>). IF you work with low level image or video processing, you typically end up with several nested for loops and a state machine (it is never a simple for loop) just to express the standard sequence operators. When you add this code plus the complex maths and protocols in the code anyway, anything that increases readability is a Godsend.

That is singularly the greatest addition to C# in my opinion. If people have issues with performance then use C++ but I use them in pretty hardcode situations, where the customer complains abaout any slowness, and they are still quick

18 hours ago, W3bbo wrote

I agree, but that approach doesn't lend itself to making lots of extensions for a large number of types, as you have to create a new type for each of them (even if you're only adding a single new member).

An advantage of the 'extension class' approach is you can now have extension properties (without any weird convulted syntax).

The language designers could add both approaches, but then they'd get shot down for language bloat. I guess we're stuck.

Do you really think the following is too verbose? It looks pretty clear and concise to me. It only adds three total extra lines for each type you want to extend.

public extension class SomeExistingClass
{
    public string DoSomethingNew()
    {
        //...
        return result;
    }
}

@BitFlipper:Thing is, I'm not so sure extension methods would have been added without Linq, though most people complain that they want to extend types and so on, otherwise we would have heard extensions methods pre-Linq. They were an enabler of the technology, rather than a language feature like generics

@vesuvius:

Yes true, but you have to agree that the way extension methods have since been used and abused in cases that have nothing to do with LINQ just shows that it is something that a lot of people want to use, and obviously find that it is useful to them.

I'm just suggesting a way to clean it up and make it more consistent with the rest of the language (we all know how partial classes work). The current extension syntax is convoluted and limiting and doesn't seem to fit in with the rest of the language (it seems contrived to me).

@BitFlipper: The problem with your syntax is that the extension class would have to be in the same namespace as the original, which means it'll typically be in a completely different namespace than anything else in your assembly. And if you stick with the current way of importing extension methods, there'd be no way to import the original type without the extension methods if they're referencing your assembly.

That syntax is very similar to how Ruby handles extending classes.

17 hours ago, vesuvius wrote

@Bass:LINQ-to-Objects. Some people seem to thing it looks fancy in code (I guess?), but I don't think it makes the code any clearer then a simple foreach loop (which tends to be faster anyway). See above also.

I have to say I think code is eminently more readable when you have a .Any(a=>) or .All(a=>) or .Skip(a=>). IF you work with low level image or video processing, you typically end up with several nested for loops and a state machine (it is never a simple for loop) just to express the standard sequence operators. When you add this code plus the complex maths and protocols in the code anyway, anything that increases readability is a Godsend.

That is singularly the greatest addition to C# in my opinion. If people have issues with performance then use C++ but I use them in pretty hardcode situations, where the customer complains abaout any slowness, and they are still quick

I think normal code tends to be far more readable then complex LINQ or SQL statements.

@Sven Groot:

Sorry I don't understand why there would be any such a limitation. Why can the compiler create extension methods right now without the code being in the same namespace, but won't be able to do essentially the exact same thing but with only syntactic differences from the current implementation? What technical reason do you foresee that would require the extension class to be in the same namespace as the original?

EDIT: I suspect you are thinking too much about how partial classes work. It doesn't mean the same restrictions need to apply to extension classes as those that do to partial classes. They would be different concepts, each with their different set of restrictions. The namespace restriction doesn't need to apply at all to extension classes, just like they don't apply to extension methods right now.

Okay, so let's say I have this:

namespace Foo
{
  public extension class String
  {
  }
}

How would the compiler know that the extensions are for System.String and not for Other.Namespace.String?

Obvious?

public extension class System.String

Evil variant for those who can stand the syntactic similarity but different interpretation to an unspecified foreign language entity

public class String extends System.String

@Bass:Are you implying statements are more normal than expressions?

@Sven Groot:

How does the compiler know which class to extend with the current extension syntax?

2 hours ago, BitFlipper wrote

@Sven Groot:

How does the compiler know which class to extend with the current extension syntax?

The class' type is specified as a parameter to the method, so the type name just needs to be qualified as such:

using MyNamespace1;

namespace MyNameSpace2 {

public static class Extensions {

public static void MyExtensionMethod(this MyClassInNamespace1 item) {

}

}

}

@W3bbo:

Correct, I'm just trying to understand the problem that Sven identified.

So far I have no complains. Doing some C++ project right now, and I so hope I can use C#. It is not just GC thing, but, so many simple things like Random/Collection (rand, vector) etc is much harder to use compare C# classes. And the naming on C# is much human readible instead of some whacky short names. And I hate header, eekk.

I am sure C# is some short coming, but, I cannot remember what they are, which is a good thing. Meaning it is not pissing me off enough for me to remember.

There's a second Jon Skeet presentation about C# weirdness/abuse. There's a pretty interesting gotcha about enumerators in there:

Abusing C#

I know I'm going to be rewriting some experimental code based on this at least.

It's not a mistake per se, but C# and the .NET Framework need some notion of higher kinds to take things to the next level, I think.