|
Glad you like the Line Counter add-in. I've been poking at it lately, trying to improve it and make it work with VS2008 too. Hopefully another version will be released soon.
As for C# 3.0/.NET 3.5, there are LOTS of useful things. WPF is certainly more resource heavy than basic windows forms, but its only one of the many new things available. You also have WCF, WF, LINQ (which isn't just for querying databases...it queries any enumerable type which is GREAT, you'll love it), anonymous types, partial methods, expression trees, class initializers, HashSet, and more. The LINQ features, which is where IEnumerable.Any comes from...its a part of LINQ, are probably the most useful addition to the language.
|
|
|
|
|
Yeah, I'll definately have to upgrade to VS2008 and start using the new stuff. That's cool that you have been poking at the line counter. I wouldn't mind seeing a toolbar added and the ability to calculate the contents of a folder. Calculating basedon namespaces, classes, interfaces etc. would be nice too but I imagine that would be a lot more work than folders.
|
|
|
|
|
Can anyone say partial properties? Being able to add attributes to properties created in generated code would be awesome (using a the MetadataType approach is such an ugly hack).
I would also love to be able to add extension methods to a static class. I know everyone has wanted to add some functionality to Membership or Math.
|
|
|
|
|
What's wrong with out parameters?
|
|
|
|
|
|
Only used beer is free. 
|
|
|
|
|
|
I'd like to see built in threading.
Example:
int x = CalcXDataValues() & <- run as thread
int y = CalcYDataValues() &
int z = x + y; // will not execute until x and y are set!
- Pete
|
|
|
|
|
I would like to be able to do something like this:
const string[] constantArray = {
"String1",
"String2",
"String3"
};
Right now you can only create a static read only array.
|
|
|
|
|
I'd like to see operator overloading supported in Interfaces, but this obvious has problems for languages that don't support op overloading.
Here's what I'm thinking
interface INumeric {
... overloads for +, -, /, *, remainder, (others)
}
class stats<T> where T:INumeric {
... methods to calculate staticial values on type T
}
This doesn't have to be done with interfaces (that just seems easiest). If all the numerics shared a common base class that would also be ok.
I realize that this can be done with out op overloading (using only method calls), but I'd like to see it build-in so the standard types implement a basic set of operators, and users could implement their own (possibly) wacky types. That way the possibly complex methods used to calculate need only be written once.
Consider, calculating Navier–Stokes equations over a large region, then as you drill down into a small region you find that you need more precision than the ~15 of doubles, so you write a high precision class that is much slower but provide the precision required. If there were a natural way to create such a class then it could just be plugged in via generics rather than requiring a bunch of complex equations to be rewritten for the new type or for method (rather than operator) expansion.
Ok, that's enough wackiness for one day
|
|
|
|
|
Default initialization on auto-implemented properties!!
I'm on a Fuzzy State: Between 0 an 1
|
|
|
|
|
I have 5 that I want
Basic stuff:
1. I'd like compile-time calculation and compile-time execution support. I'd like to have a compile-time assert, as well as simple calculations. I don't want to do calculations at runtime on static data I have a compile time.
2. I'd like to see language support for mixins.
3. I'd like to be able to write "const-correct" code the way I can in C++. I'd like to be able to mark a method read-only so that I know it doesn't modify the data. I'd like to be able to have a read-only object and pass it to other functions knowing that they cannot modify it. This really helps when reading other people's code, too, 'cause you can easily determine their intent.
The following I think are features that the language will eventually have -- mark my words.
1. Language support for mocking. For instance, I should be able to instantiate an interface and get some dummy default implementation. This will help with stubbing. And I should be able to configure the mock in a simple way to do some other "basic" functions.
2. Language support for unit testing. I realize that everyone's thinking why, 'cause NUnit works, etc. But if you allow your mind to wonder why it would be like to have language support for Unit Testing, you can imagine some interesting possiblities. For instance, how about methods won't compile unless they have tests. Or if every path doesn't isn't executed, then you get a compiler warning. Maybe those aren't the best examples, but smarter people can come up with something more interesting.
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
I don't know what I'd put in, but I know what I'd 'take out'. I'd restrict the use of the 'var' keyword to the Linq domain, only. I see major abuse coming, and I don't relish maintaining code which uses the 'var' keyword in a profligate fashion.
D. T. Doutel
|
|
|
|
|
Here here! var should only be used when you don't know the type!
|
|
|
|
|
Perhapse that should be worded "can't" know the type...as in the case of anonymous types. Its easy enough to debug and find out a type you don't know. Var has its uses, but like almost any language feature, it can be missused. I think rather than restricting its use, though, better educating our programmers and instilling good practices is the first thing we should try. 
|
|
|
|
|
Jon, you can educate the programmers until you're blue in the face. But, when crunch time comes and all hell breaks loose, then we all take the quick and easy way out. Once you get used to using var (as with any shortcut), you'll continue using it. Usually, the best way to prevent using it (in a company or an organization) is to specifically disallow it in the coding standards and check for it in the code reviews.
|
|
|
|
|
Jon Rista wrote: should be worded "can't"
Yes, but for me they're pretty much equivalent; if I can know it I do know it.
Unfortuntely there are some who can know it but are too darn lazy to find out.
|
|
|
|
|
By "can't" I really meant can't. There IS no type for an anonymous type at design time...only at runtime. In that case, use of var is the only possability. You physically can't know the type.
|
|
|
|
|
|
Design by Contract.
There's support for it in one of those little extra languages that they fiddle around with, but I'd like to see support (language-level? just a library?) for it in C#.
|
|
|
|
|
I agree, I think Spec# should be integrated into C# 4.0. Design by Contract is better than just adding support for const. I want all my contractual features...function purity, non-null parameters, input requirements and output ensures, etc. I can't wait for the day when my code is not only well written, but contractually secure.
|
|
|
|
|
What every language needs, and what every virtual language lacks: the ability to do inline assembly where necessary with the understanding that makes your code non-portable.
For some stupid reason, I'm currently working on a project that is testing hardware at a very low (sometimes pre-boot) level- but the primary languages seem to be VB.NET and C#.
It's highly frustrating. I realize this would be dangerous and that most programmers out there aren't at a level where they could make proper use of it, but having NO capability for it is ridiculous.
|
|
|
|
|
And an ability to know what version is being used, to enable conditional compilation in a standard way:
public static string F
(
# if VERSION>=3.5
this
# endif
string S
)
{
...
}
|
|
|
|
|
That would be very nice to have.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
1. Retry keyword, from VB.NET (structured error handling)
2. Dyanmic intefaces, from VB.NET
3. AppActivate function, from VB.NET
4. Non-beta version of the parallel task library
5. Better WPF designers
6. Better user experience when working on single code file shared between .NET Framework and .NET Compact Framework projects
7. Improved keyboard/focus and dynamic control creation support in .NET Compact Framework (support for ActiveControl, ControlAdded/Removed events etc).
8. Fix for the (very rare) bug caused by compiler optimisations on the String.IsNullOrEmpty function.
9. A version of the various TryParse functions that returns the default value for expected type, instead of returning true/false with an out parameter.
10. TryParse on System.Enum.
Probably a lot of other stuff too, but that's all I can think of off the top of my head 
Tuples would also be cool 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
