Coffeehouse Post

Single Post Permalink

View Thread: C#'s biggest mistake
  • User profile image

    , Bass wrote

    Generally speaking C# is a good language. I don't know what would be the worst things, but this is what I don't like.

    • More of the .NET thing, but the prefixing of the interfaces with "I". Just looks ugly to me, and I think it discourges use of interfaces when they really should be used (I don't see IList used so often, even though "List" is an implementation I've seen methods that only accept it).
    • As we were talking above, I think the collections in .NET are generally poorly designed.
    • The C++ syntax for class inhertence. It makes sense in C++ because there is no language distinction between interface and class. They should have taken Java's syntax for this.
    • Multiple language features that do similar (or even the same thing). One example: lambda vs anon functions.
    • 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.

    The IInterface thing is from COM, but I prefer it because often you have types and related interfaces that should have the same name, but without the I prefix you'd get a collision. It is interesting how it's the single exception from the "strictly no hungarian" rule in .NET.

    It also makes it possible to glance at a type definition and see what types it extends vs what interfaces it implements.

    I wouldn't say they do the same thing: Lamba functions are an application of anonymous methods (and as far as CIL is concerned, they're the same thing). It's like saying we shouldn't have verbatim "@" strings because you can express their contents as regular strings.

    Linq-to-Objects is meant for complicated in-memory object graphs. Outside of data access (which we've got Linq-to-Sql for anyway) I can't see many applications. Maybe in massive data visualisation, but I've seen more people abuse it or make something overly complicated.

    , felix9 wrote

    personally I want:

    array on stack and array embedded/inlined in struct
    indexed property
    event assigning in the object initializer block
    more flexible and powerful generics type parameter constraints, like valuetypes and math operators

    You can already do array-on-stack using the stackalloc keyword and struct arrays with the fixed keyword. The only catch is it's got to be within an unsafe context. For example:

    unsafe struct Foo {
        public fixed char[128];
        public static Bar() {
            int* baz = stackalloc int[ 512 ]; // create a 512-element sized array on the stack, it does not need to be freed

    indexed properties... they already exist with the 'this' property, so what you're actually after is named indexed properties. The thing is that such a system would conflict with the current 'this' property (e.g. what happens if a named-indexed-property returns an object with a 'this' property?).

    , BitFlipper wrote

    I think the way they implemented extension methods is too limited, convoluted and broken. There is a much cleaner and easier way. They should have used the same concept as a "partial" class, and implemented extension methods like this

    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.