Comment by dschobel | Hacker News Reader

Comment by dschobel | Hacker News Reader

Parent Full thread

not a transcript but some notes of his wishes and complaints for the language.

----------------------------------

wish: static interfaces for use in the context of generic type constraints

    static interface ISummable<T>
    {
        T operator +(T arg1, T arg2);
    }

  which then lets you write

    static T Sum<T>(IEnumerabel<T> source) where T : ISummable<T> { }

----------------------------------

gripe: array covariance (which the designers copied from java even though people knew it was a mistake even when java had it):

    //the following is still valid and will happily compile and run
    string[] strings = new string[5];
    object[] objects = strings;
    objects[0] = new Exception();

----------------------------------

wish: non-nullable references (ackowledges that it is a hard problem but "it would be nice to have")

----------------------------------

wish/gripe: c# enums are labels for numbers which let you write things like:

            enum Color {red = 0, green = 1, blue =2}
            Color c = (Color) 5;
            Color c2 = 0.0;

he wants to see java-like enums which enforce the idea that you're dealing with a restricted set of values.

----------------------------------

wish: Read-only keyword for auto-properties

.net 3 made it easy to tack mutable properties onto your class

        string Name{get;set;}

Jon wants to see:

    string Name{ readonly get; }

which tells the world that not only is Name immutable externally to your class, but internally as well.

    string Name { get; private set; }

does not get you there, since the property is still fully mutable within your class.

----------------------------------

wish: sealing/unsealing classes

this was his self-proclaimed controversial point

he either wants to see classes sealed by default and then unsealed with an explicit 'unsealed' keyword or he wants the default class template in Visual Studio to demand that the programmer pick one or the other

----------------------------------

gripe: object is bloated, cut Equals() and HashCode()

writing equals in a type hierarchy is a pain and gets messy when you drill down into the derived types

let authors "opt in" to equality

want a map of <T>? or a dictionary of <T>? you have to provide an equality comparer

"there doesn't have to be one canonical idea of equality for a type so why is it in object"?

Excellent. Thanks for that.

This is good thread also

http://social.msdn.microsoft.com/Forums/en/csharplanguage/th...

Object is bloated? That's an odd complaint. Much like array covariance, object was pretty much directly copied from Java.

I disagree on getting rid of Equals if for no other reason it's implicitly used often (like in collections). And if there is no canonical idea of equality, that's what overriding Equals is for, and what Object.ReferenceEquals is for (return yourself to the base notion of equality when you need it).

It's a mistake in Java too. It's often convenient to simply skip implementing equals() and hashCode() because you don't plan to use an object as the key to a map. In that case, attempting to use it as a key should fail to compile, so you know you need to go back and add it.

The Comparable interface shows how it should be done.

(But on the other hand, if you were starting over it would be better to learn from Go's interfaces.)

Uh oh, I wouldn't want anyone to copy anything that has to with typesystem from Go before they tell how they are going to have typesafe containers without generics. Haskell typeclasses would be a better source of inspiration IMNSHO.

His argument is that the concept of equality will vary by application and a default implementation adds very little. For example, does it make sense to test equality on a filestream? Probably not, but it's there and it purports to have some meaning.

This of course, only makes sense in the post-generic world of .net +2.0 so he does excuse their presence as a vestige of 1.1.

But simple equality often does make sense in the context of collections. Am I going to throw filestreams in a collection, probably not, but I very often throw all kinds of objects in a collection and the base object.Equals very often fits my needs there perfectly.

I dunno, I haven't actually watched this presentation so maybe I just need more context. But I've been programming in C# since it came out and not once have I ever had any real issues with Equals and all of its related methods.

I agree that as a practical matter it does what you want a majority of the time but generic collections let you mandate that an author has thought about equality for his object at least a little by implementing IEquatable. Particularly since a default definition of equality doesn't always make sense (as in the case of the fs).

As with the case of explicitly sealed/unsealed classes, it seems like Jon's MO is to make programmers think about some of these things more carefully rather than have a "correct 90% of the time" default; a sentiment which I can definitely appreciate. :)

Anyway, he discusses it at approximately the 36 minute mark. Well worth a look.

Object is bloated? That's an odd complaint. object was pretty much directly copied from Java

What are you saying - that if it was copied from Java, it must be OK? It is not impossible that object is both copied from Java and bloated.

I disagree on getting rid of Equals if for no other reason it's implicitly used often

But it isn't used often. Take an application of yours. What percentage of the types that you have defined in it need to worry about equality over and above ReferenceEquals? You may have collections of customer, but never collections of CustomerFactory, CustomerRepository, CustomerController, CustomerEditForm, etc...

And if there is no canonical idea of equality, that's what overriding Equals is for

If you override equals, you can only have one kind of non-reference equality per type, which is what Jon Skeet says is not always the right thing.

I'd love immutable auto-properties. They'd make a lot of my code cleaner.

How would the fact that you cannot modify a property from within the class make the code cleaner? You can achieve exactly the same by sticking to a convention. It's impossible to fully protect a class from the inside anyway, so I don't see a lot of benefit from such a feature.

The automated property generators are just syntactic sugar. At the moment, if I want a property that's settable inside and out I can can type:

  public string MyString{set;get;}

In order to do the same with an immutable property requires a fair bit more code.

  private readonly string myString;
  public string MyString
  {
    get
      {
         return myString;
      }
  }

Replacing all of that with

  public readonly string MyString{get;set;}

would be handy, and work with the way the language currently does.

Deleted comment

Oh, absolutely. It's not vital - it's just that with there being more multithreaded stuff going on I'd like easier ways of making it clear what's immutable and what isn't.

Heck, I'd love a way of saying "immutable class" in the same way you can with a "static class", just to ensure I haven't missed anything!

I deleted my previous comment shortly after posting because I realized that you're right, this would be definitely useful. I haven't noticed that you already managed to reply to it.

Reply on news.ycombinator.com