4 ms·
not a transcript but some notes of his wishes and complaints for the language. ---------------------------------- wish: static interfaces for use in the conte
by dschobel 16y ago
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"?
- gtani 16y agoExcellent. Thanks for that. This is good thread also http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/47d10fcb-2d69-451a-bb97-023f1f9113f3 http://social.msdn.microsoft.com/Forums/en/csharplanguage/th...
- city41 16y agoObject 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).
- dschobel 16y agoHis 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.
- city41 16y agoBut 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.
- dschobel 16y agoI 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.
- AndrewDucker 16y agoI'd love immutable auto-properties. They'd make a lot of my code cleaner.
- adambyrtek 16y agoHow 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.
- AndrewDucker 16y agoThe 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 16y ago[deleted]
- AndrewDucker 16y agoOh, 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!
- adambyrtek 16y agoI 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.