4 ms·

It's sad how C# is put on a pedestal, since it has plenty of obvious critical flaws, see links below for a list and this is just the tip of the iceberg. http:/

It's sad how C# is put on a pedestal, since it has plenty of obvious critical flaws, see links below for a list and this is just the tip of the iceberg. http://hestia.typepad.com/flatlander/2012/01/action-func-void-and-unit.html http://hestia.typepad.com/flatlander/2012/01/action-func-voi... http://trelford.com/blog/post/LighterCSharp.aspx http://trelford.com/blog/post/LighterCSharp.aspx http://stackoverflow.com/questions/411906/c-sharp-net-design-flaws http://stackoverflow.com/questions/411906/c-sharp-net-design... http://joeduffyblog.com/2010/06/27/on-partiallyconstructed-objects http://joeduffyblog.com/2010/06/27/on-partiallyconstructed-o... http://blogs.msdn.com/b/dsyme/archive/2013/03/25/quote-of-the-week-quot-what-can-c-do-that-f-cannot-quot.aspx http://blogs.msdn.com/b/dsyme/archive/2013/03/25/quote-of-th...

mcgwiz 13y ago
Whitespace insensitivity and inability to return void in generic contexts are "critical flaws"? Anyway, no one's saying C# is flawless. Personally, I would love the ability to declare immutable graph references.
V-2 13y ago
http://hestia.typepad.com/flatlander/2012/01/action-func-void-and-unit.html http://hestia.typepad.com/flatlander/2012/01/action-func-voi... I fail to see how it is an "obvious critical flaw" :) You have to create a separate overload that takes an Action instead of a Func, and has an identical implementation except for omitting the return keyword. Granted, that’s not much work for a simple helper like the above, but what if it were more complicated? No, it's simply not true that you need "an identical implementation except for omitting the return keyword"... Eg. this would do the trick without repeating the implementation: http://pastie.org/8628864 http://pastie.org/8628864 Just two one-line overloads as entry points.
- raphaelj 13y ago
  Your solution is at least as ugly as the one mentioned in the article. The problem is that void can't be used as a regular type identifier. In a lot of langages (like Python, Haskell, F#, ...) there is a regular type for void. This type is often implemented as such : sealed struct Void { } Then you can define Action<...> just as Func<Void, ...>. As the compiler is smart enough to see there is only one kind of Void value, it can be entierly removed from the generated code and thus doesn't make your code slower.
  - V-2 13y ago
    And quite what's so ugly about it? It's hackish, but once you create these overloads, you don't need to worry about it anymore and you can call the method just as if Func<T> could be casted to Action. I don't think it can even be compared to the one suggested in the article, since it does not require "creating a separate overload with an identical implementation" (!!!), potentially copy-pasting hundreds of lines of code if the method in question was indeed "more complicated". This is ridiculous and the fact the author couldn't think of a workaround that didn't involve it baffles me.

mcgwiz 13y ago

Whitespace insensitivity and inability to return void in generic contexts are "critical flaws"? Anyway, no one's saying C# is flawless. Personally, I would love the ability to declare immutable graph references.

V-2 13y ago

http://hestia.typepad.com/flatlander/2012/01/action-func-void-and-unit.html http://hestia.typepad.com/flatlander/2012/01/action-func-voi... I fail to see how it is an "obvious critical flaw" :) You have to create a separate overload that takes an Action instead of a Func, and has an identical implementation except for omitting the return keyword. Granted, that’s not much work for a simple helper like the above, but what if it were more complicated? No, it's simply not true that you need "an identical implementation except for omitting the return keyword"... Eg. this would do the trick without repeating the implementation: http://pastie.org/8628864 http://pastie.org/8628864 Just two one-line overloads as entry points.

raphaelj 13y ago
Your solution is at least as ugly as the one mentioned in the article. The problem is that void can't be used as a regular type identifier. In a lot of langages (like Python, Haskell, F#, ...) there is a regular type for void. This type is often implemented as such : sealed struct Void { } Then you can define Action<...> just as Func<Void, ...>. As the compiler is smart enough to see there is only one kind of Void value, it can be entierly removed from the generated code and thus doesn't make your code slower.
- V-2 13y ago
  And quite what's so ugly about it? It's hackish, but once you create these overloads, you don't need to worry about it anymore and you can call the method just as if Func<T> could be casted to Action. I don't think it can even be compared to the one suggested in the article, since it does not require "creating a separate overload with an identical implementation" (!!!), potentially copy-pasting hundreds of lines of code if the method in question was indeed "more complicated". This is ridiculous and the fact the author couldn't think of a workaround that didn't involve it baffles me.