3 ms·

Anders isn't a huge fan of events, apparently (http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Questions-and-Answers http://channel9.msdn.com/Shows/G

Anders isn't a huge fan of events, apparently (http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Questions-and-Answers http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Q..., around 56:00). I always just initialize events with an empty delegate in personal projects, which is very much the wrong thing to do but it saves me the null ref headache. I would personally like to see `var` available in private and internal class members (properties, fields, and methods). There's a lot of pointless repetition that could be eliminated. (Obviously, you want to be explicit about the interface defined by a class' public members). I also consider Tuple<> a missed opportunity, I'd like to see another whack taken at it that veers closer to structural typing. The existing tuple type is very unwieldy once you start returning or storing it, and I feel a pretty good alternative could be built on the principles of `var` and anonymous types. Picturing something like: static tuple SomeMethod(){ return new tuple { SomeNumber = 1, SomeString = "hello" }; } static void Main(){ var t = SomeMethod(); Console.WriteLine(t.SomeNumber + " "+t.SomeString); } Whereas Tuple<> forces you to write that with ItemX scattered around.

frou_dh 15y ago
Thanks for the link. I haven't used C# 4.0 or later, but your anonymous tuple thing looks good.
Someone 15y ago
Except for that 'tuple' after 'new', how is http://msdn.microsoft.com/en-us/library/bb397696.aspx http://msdn.microsoft.com/en-us/library/bb397696.aspx different from what you want?
- bunderbunder 15y ago
  Anonymous types can only be used for local variables. They cannot be returned from procedures, passed as parameters, or assigned to fields. Tuples, on the other hand, are full-fledged generic classes. That introduces an advantage in that they're first-class entities which can be used anywhere. But it introduces a couple disadvantages, too: There's a separate class implementation for each number of elements, and implementations are only provided for up to 7 elements plus an 8th weird kludge for supporting more. And having the tuple's "official name" be Tuple<$ARBITRARY_LIST_OF_TYPES> is not only cumbersome, but also misses an opportunity to do a better job of communicating semantics. Consider, for the sake of argument: Tuple<Employee, int, string, double, string, bool> versus Tuple<Employee, int?, string, double, string, bool> What's going on here? Are they equivalent? What are they being used for? What's up with the different types for Item2, are they equivalent? For that matter, what about Item3? Sure it's got the same type, but we've really got no idea what it's being used for. And since it's being implemented as a plain old generic class, there's no class definition on which you can lay some documentation about this stuff. Just a bunch of disembodied type declarations all more-or-less equivalent to each other. You know that phase in a lot of beginning programmers' careers where every variable is named foo1, foo2, etc? This is in many ways the same thing, only codified and enshrined by the .NET Framework designers. Oh, and the word's "Item" instead of "foo". Practically speaking, it means that Tuple's crippled. Sure, technically you can use it for anything. But if you're the kind of person who likes maintainable code, you really don't want to be using it for anything but the most trivial cases. You certainly shouldn't be using it in any interfaces that other people are going to have to work with.

frou_dh 15y ago

Thanks for the link. I haven't used C# 4.0 or later, but your anonymous tuple thing looks good.

Someone 15y ago

Except for that 'tuple' after 'new', how is http://msdn.microsoft.com/en-us/library/bb397696.aspx http://msdn.microsoft.com/en-us/library/bb397696.aspx different from what you want?

bunderbunder 15y ago
Anonymous types can only be used for local variables. They cannot be returned from procedures, passed as parameters, or assigned to fields. Tuples, on the other hand, are full-fledged generic classes. That introduces an advantage in that they're first-class entities which can be used anywhere. But it introduces a couple disadvantages, too: There's a separate class implementation for each number of elements, and implementations are only provided for up to 7 elements plus an 8th weird kludge for supporting more. And having the tuple's "official name" be Tuple<$ARBITRARY_LIST_OF_TYPES> is not only cumbersome, but also misses an opportunity to do a better job of communicating semantics. Consider, for the sake of argument: Tuple<Employee, int, string, double, string, bool> versus Tuple<Employee, int?, string, double, string, bool> What's going on here? Are they equivalent? What are they being used for? What's up with the different types for Item2, are they equivalent? For that matter, what about Item3? Sure it's got the same type, but we've really got no idea what it's being used for. And since it's being implemented as a plain old generic class, there's no class definition on which you can lay some documentation about this stuff. Just a bunch of disembodied type declarations all more-or-less equivalent to each other. You know that phase in a lot of beginning programmers' careers where every variable is named foo1, foo2, etc? This is in many ways the same thing, only codified and enshrined by the .NET Framework designers. Oh, and the word's "Item" instead of "foo". Practically speaking, it means that Tuple's crippled. Sure, technically you can use it for anything. But if you're the kind of person who likes maintainable code, you really don't want to be using it for anything but the most trivial cases. You certainly shouldn't be using it in any interfaces that other people are going to have to work with.