What features would you like in the next version of Visual C#?


I ask this question because C# 2005 is getting more and more solidified as we approach the release date. Adding new features at this point involves determing how much benefit the user will get out of it versus the cost to design, implement and test that new feature. As we get closer to ship date the feature has to get more and more compelling with less and less cost. This is an example of “raising the bar”. If we don’t keep that bar high then we’ll introduce something that we don’t have enough time to get to the quality that people want and we run the risk of destabalizing the product.

This also means that as time goes on features that are currently in the product might get cut. Even if they provide high user value, if there isn’t enough time for a dev to implement it it will be cut. If the dev can (or has) implemented it, but there isn’t enough time to test it, it will get cut. I’ve had this happen with three features that I added in my spare time. Anson and Kevin both experienced this as well. It’s kind of depressing, but with a limit on how many resources you have it just happens. I’d like to talk about those features to get some feedback on how useful people find them, but I’ll have to run that by Jay first to know if that’s ok.

However, when we cut something we don’t say “we’re not going to do that ever,” instead we say “we’re going to postpone work on that and come back to look at it later.” Then, when we add that to the list of things we want to do for the next version. When we get around to planning that version we prioritize those features, try to estimate how long it will take to add them and then we pick a subset of all the things we have that we feel will provide the best user benefit.

Features that are chosen then have a very high chance of staying in the product. Features added later have a much higher chance of getting cut because they add pressure on everybody later in the game when, most likely, all schedules are packed. Cutting current features to make time for the new features is a tough sell because of all the time already spent and also the risk of destabalizing when you remove that code. All in all it’s a tougher thing to do. Note: this is just a simplistic view of things from a dev’s perspective. Anson and Jay would probably be able to explain this a lot better from a PM and Lead’s perspective.

So, if you have features that you really want in the next version of the product, now is the time to ask for it. We’ll add those to the list and if they’re good then they’ll get done. Note: feel free to make suggestions about any part of the products, but know that we (well me specifically) are focussed on the code editor and compiler for C#. We’re very interested in everything else (like WinForms or the base class libraries), but other teams take care of those so they’d understand it better than we might. However, we’d send all of this information to the teams appropriate to handle it.

I might add that detail would be appreciated with the responses. Rather than just “add emacs support” explain in depth what aspects of emacs you really like and how they would benefit you substantially. For example, is it just the keybindings, is it something about the interaction model, etc.? You also don’t have to talk about humongous feature additions like “vs should add refactoring support”, you can instead talk about little things that drive you nuts in VS7/7.1. Like “i hate it when I’m typing and ‘foo’ happens and suddenly I have to stop what I’m doing to fix it,” or “why can’t the C# editor help me when I’m doing ‘bar’? I waste so much time doing it over and over again”. These can also include things related to exposing libraries for you to interface with as opposed to just features in VS that you interact with. If you wanted programmatic access, what would you like to see exposed?

Maybe I’ll be able to tell you: “Hey!! We added that in C# 2005.” Or maybe we’ll actually realize that what you’re talking about is a bug that we should fix before 2005 ships. But if it isn’t one of those then we will add it to the list of features to consider for the next version and you will have a chance to get what you want.

I wish that we had a better system for doing this rather than asking every so often on a blog. A public suggestion system would be ideal. Preferably with two way communication so that people would know that they were getting heard and that these features were being considered. But until we have that, I’ll have to do this the hard way.

If you think C# is perfect, then feel free to keep quiet. However, I certainly think that it could be improved immensely and I want to try to do it in a way that benefits all of you. I’d also like it so that in the future we had a much faster ship cycle. That way if you wanted a feature we’d be able to get it to you in 3-6 months. Currently we have a cycle that is multi-year. So we ship a product that is much improved across the board. But if we don’t have the feature you want then you’re not going to be getting it for another few years. Note: things like ship cycles are also things that you can request. If you want us shipping faster, let us know. Later on I’ll try to bring up the issues surrounding that. But if you do find that compelling, let us know!

Let me explain. No, there is too much. Let me sum up: let us know!


Comments (164)

  1. David Levine says:

    Ah, feature request time….

    These are more a DevStudio requests then a C# request but I’ll throw it out there anyway. 1., edit-and-continue.

    2. allow us to select different color schemes (foreground/background) for text within different regions.

    3. Autogenerate unit test skeletons for objects that I create. TDD is extremely useful but needs better support from the tool vendors.

    4. Convert a solution into a makefile.

    5. Better support for MSI file generation. The current editor works well enough to make you want to use it, but not well enough to be really useful.

    Ok, here are some C# specific features…

    1. Expose a syntax for user-filtered catch handlers. Allow us to call arbitrary code from within the filter to determine if a particular catch block will be selected as the handler.

    2. Provide a module that does the low-level work of hooking the profiling API, and then provide events, etc. to notify managed code when significant events have occurred. Make this available as a BCL.

    Runtime issue

    1. Notify a callback/fire event when an exception is thrown but before any other actions have taken place (i.e. before it searches the callstack looking for a handler).

    Tools:

    1. A way to enumerate all the different modules loaded into all the different fusion contexts – this is useful when trouble-shooting issues related to using plugins.

    2. A static analysis that can evaluate the binding order the runtime will use for a particular assembly, i.e. follow the chain of publisher policy, appbase and private probes, etc.

    I realize that you may consider most of these requests as not part of C# itself, but from an outsider’s perspective I see C#, DevStudio, the BCL, the runtime, and the tools as part of a package that I use together. You may have a bright line dividing them but I deal with them as a unit.

  2. 1. Edit and Continue

    2. Edit and Continue

    3. MSI support for the following: Feature groups with interface that allows selection of Typical, all Custom etc. and allow us to customize these and define which components will be put into it. And an editor for the dialogs.

    4. Edit and Continue

  3. Wallym says:

    Edit and Continue. I didn’t think of how big this issue was when it was first talked about in the beta days of .NET 1.0. This is a major issue. Debugging an application with Edit-n-Continue that requires that you take 10 minutes to get the application into a certain state can greatly improve developer productivity. the team stuff is nice and great, but EnC is a major issue. Yes, there are a lot of people out there that say that you only had this in VB, so if you come from the C world, you didn’t have this so you aren’t missing anything. I believe that these are the same people that when told that the masses did not have enough bread stated "Well, let them eat cake."

    Simpler debugging with threads. I would like to lock down and traverse through one thread when I debug instead of all threads being tracked. Think of this like an added feature of breakpoints where you can break on not just the line of code, but also on the threadid, or something like that so that I can track thru and see what is going on with a certain thread.

    Wally

  4. Jim Arnold says:

    * Expose the compiler with a managed API so I can parse C# files into a CodeDom tree (or just implement ICodeParser properly).

    * Syntactic sugar (or smarter delegates) so we don’t have to check events for null before firing them.

    * Methods virtual by default :-)

    * Some funky syntax so I can construct an array inline when calling a method, eg:

    Foo({1,2,3});

    void Foo(int[] arrayOfInts)

    {

    }

    (I haven’t thought too hard about that one and it might not be statically inferable, but it seems like it should work).

    * Built-in checking on enums so you can’t cast one from an out-of-range value.

    * Restrict usage of ‘goto’ to switch statements.

    Jim

  5. David Campeau says:

    Not C# specific but DevStudio related:

    Add Some new view to Solution explorer:

    We now have 2 view

    1) Normal with all file in the project arranged in a tree.

    2) Hidden files are shown.

    I would like to filter the first one by only the openened ones. ( because, lets be blunt. the current tab view for opened files blows!)

    Ex (number denotes level in the tree):

    1- Application

    2- Folder1

    3- File1.cs

    3- File2.cs

    3- File3.cs

    2- Folder2

    3- File4.cs

    If only File2.cs is opened i would only see:

    1- Application

    2- Folder1

    3- File2.cs

  6. Duncan Godwin says:

    * Intellisense to show a class has an indexer […], show it at the top of the list of methods or something similar.

    * Some indication that a type supports IDisposable -> create a smart tag popup for the class to provide the option of moving that class into a using block.

    * Create a constructor in a child class that calls the base class setting up all the parents parameters.

    * Copy a constructor. If I want to copy a constructor to add a parameter, I have to manually copy the definition, put all the parameters in the this(name, phone, email) etc. This could be easily automated leaving me to do the job I’m trying to do – add a new parameter as an overload.

    * At the moment there is the option to Generate Method Stub. I’d like to see Generate Class Stub. This would allow a class to be prototyped, and then the class and it’s methods generated from the usage.

    * I’d like the prop and propg templates to generate to specific regions so that they can be grouped together. I usually put private variables above the constructor and properties below.

    Cheers,

    Duncan

  7. Duncan Godwin says:

    One more…

    * For regular expressions to be treated as an operator as the are in JavaScript and Perl.

    e.g.

    if (/w{3,6}-d+)/) {

    // do something

    }

    This would get rid of a lot of the unnecessary escaping of characters that goes on now.

    Cheers again,

    Duncan

  8. 1) Edit and Continue

    2) Option so i can turn specific warning(s) to errors

    3) VS macros in C#

    4) True managed AddIns (or is it VSIP?), no COM tricks to distribute an AddIn, just XCopy deployment

    5) Add a Property at the Project’s directories named "Default Namespace" that overrides Project’s, so i can group many files of the same namespece in different directories or support many root Namespaces in the same project

    6) Obfuscator API, so i can apply my rules how and what will be Obfuscated and (_the_most_important_) the translation results (map?) are written to the pdb. That way i can distribute an Obfuscated dll, but if i want to debug it, with just a copy of the pdb in the same directory, i will be able to see in VS the real symbols and not the Obfuscated

  9. Cleve Littlefield says:

    First of all, thanks for asking! Second, a lot of people have given some good suggestions, a few of which I will repeat here to emphasize:

    1. Edit and Continue (Of Course!)

    2. Managed, easy to write add-ins

    3. Interface into the code parser (ICodeParser support)

    4. Interface into the Refactoring engine (allow us to write our own refactorings)

    5. C# macros

    6. Native Regex operators

    7. String.IsEmpty function that is the equivalent of this (syntactic sugar):

    if (myString != null && myString.Length != null)

    8. Anything that VB has now that C# doesnt, like the My classes, named indexors, E&C, etc, (this is a general rant, MS says all languages are equal but this is not the case, if you add something to VB add it to C#, and vice versa. These two teams should really be merged)

    9. Dynamic execution support equivalent of the eval method in JS

    10. Dynamic Mock object / code injection support (like the RAIL project), so that to use mock object I dont have to have an interface, I can just do something like AppDomain.Replace(Type oldType, Type newType) first thing in my code…

    Editor enhancements

    1. Automatically add using directives as I type (for instance if I type SqlCommand or StringBuilder, the VS editor should add System.Data.SqlClient or System.Text using directives, respectively).

    2. Support for putting all the using directives under the namespace declaration by default (this is our groups standard, and I hate it, but must conform).

    3. Built in code style checking on the fly (configurable styles of course)

    Nice to haves but not all that important

    1. Analyzer that finds code duplication / calculates cyclomatic complexity on the fly

  10. * More flexible interface implementation support. More or less how it’s done in C++/CLI or VB.NET, where I can implement under a different name and with any accessibility level.

    * IntPtr/UIntPtr arithmetic operators.

    Jim: You can already to Foo(new int[] {1,2,3});

  11. damien morton says:

    In no particular order… and maybe not for C# 2.0…

    * Covariance and contravariance of paramater and return types in interfaces and delegates. This is a purity issue.

    * A well organised set of generic collection classes

    * reference typed variables/paramaters/returntypes declarable as not-null

    * implement more of c-omega and shamelessly steal from the nice langauge

    – tuples

    – functions in module scope

    * precondition and postcondition functions delcared in interfaces

    * enforcement of rules allowing extensibility – "a sealed class cannot be used as paramater or return type of a public method – use an interface instead"

  12. Damien: Co/contravariance is supported on delgates now. Unfortunately not interface (yet). If I get my way we’ll have that though.

    We have generic collections for 2005. Is there something you don’t like about them? If so, i’ll get that feedback to the designers

    Can’t help you on the non-null part :(

    Tuples would be great. I was going to rant on that later. We’ll definitely be looking into that for C#

    Functions in module scope? Can you give an example of when that’s nice?

    Pre/Post conditions. Yep: although I’d like a more general architecture.

    Enforcment of rules: FxCop will do that for you.

  13. David:

    I like the different color scheme idea. I’ll talk about that in a later post and how to address it in a more general way

    Autogeneration of tests: Included in the new VS Team System

    Solution into a makefile: In 2k5 a solution is automatically an MSBuild makefile

    I need more feedback on how to make MSI generation better.

    C# Specific:

    Can you give me an example of where/how the exception filtering thing is useful?

    I’ll check and see if we are exposing those profiling/callback APIs through maanged code

    Your tools suggestions are excellent. Thanks!

  14. James: Tell me how you really feel :-)

    What is this Edit and Continue. It sound familiar 😉

  15. Frankie Fresh: No suggestions of your own?

  16. Wally: I’ll definitely let the debugger guys know that single stepping a thread is something you’d like to see. My guess is that it’s horrifically complex to implement and mucking with threads is something a debugger tries to keep to a minimum. I’ll see if Gregg or Steve want to respond to this.

  17. Jim: What would you do with the managed API? (Seriously, I want to know :-) )

    See Jay’s blogs.msdn.com/jaybaz_ms page on how he gets around the null check with events. But I do agree that it’s annoying for the implementor

    Virtual by default: You can get this with an FxCop rule now.

    We’re always trying to balance simplicity of work with density of syntax. is "new int[] {1,2,3}" too much clutter for you? If so, are there are areas that you would like simplified?

    Enum: Sounds good. At least for enums that don’t have the ‘FlagsAttribute’ set. Although it seems like you could write your own static method for that.

  18. Len Weaver says:

    1) Edit and continue.

    2) Covariant return types. I’d rather type this:

    public TimeSpan MyMethod() {}

    public DateTime MyMethod() {}

    …than this:

    public void MyMethod( out TimeSpan ret ) {}

    public void MyMethod( out DateTime ret ) {}

    3) Bundle an xbox with every copy of VS.net.

  19. david: I’m confused. If the files aren’t showing in the solution explorer how would you open them?

    Also, please be specific in how you don’t like the tab view for files. Just "it blows" won’t get anything fixed. But if you point to specific ways that it’s unusable, or show scenarios where it falls down, then it c an be addressed

  20. Duncan: Agreed. We shoudl show indexers, casts, possibly implemented interfaces. There are a _lot_ of things we are thinking about for how to help you out in this regard. I’m pretty certain that we’re going to be addressing all of them.

    DaigoH had the exact same idea about IDisposable. I like it. Another option is a warning if you get a disposable object but dont’ dispose it.

    I see Generate Method Stub (yaaay, my feature) evolving into a general purpose automatic generation tool. We wanted to get the most important stuff in since it was feature added so late in the game, but I think we’ll be focussing on it highly next time.

    You can change the prop template yourself. Is this something you don’t want to do?

  21. Duncan: I’m going to write a post later about embedded regexps. Neil and I were talking about this earlier and it’s something I’ve discussed a lot with my team.

  22. Cleve: What interface would you like to see the refactoring API expose?

    What would C# macros get you over running things through a C preprocessor? What power are you missing today that you think macros will get you?

    I beleive String.IsEmptyOrNull will do what you want.

    Why do you want VB/C# to be the same? If they were the same would there be any reason to pick one over the other?

    Interesting ideas about the Dynamic Mock object support. I’ll talk to jay about that.

    I added the feature to 2005 where we will add the usings for you for types that you use.

    If you add your usings under the namespace then we’ll follow that pattern and generate them there as well.

    Talk to reasearch about getting us those complexity tools :-)

  23. Len: We were thinking that an XBox2 would be better. But given yoru suggestion I think we’ll curb it back to an XBox1

  24. AT says:

    Even 5-stars product without documentation worth nothing.

    A must – better MSDN documentation.

    Show class-diagrams, relations, complete namespace/area overview.

    More best-practices. Tips ‘n’ Tricks.

    Make it’s possible to see documentation relevant not only to your language – but also .NET Framework version you are developing. (i.e. 1.0 vs. 1.1 vs. 1.2 vs. CompactFramework)

    Algorithmic complexity for methods and alternative way to get possibly the same results under a little bit another restrictions.

    Code-samples for each method/function. Make it’s possible to read big samples code right from dexplore – but without loading projects in IDE. But it’s a must to preserve all coloring and navigation like in IDE for XML and code snippets.

    Probably some kind of interactive documentation or self-assessment tests to check how you understand topics. This can be separate from MSDN product. I see some basic moves in this direction already – you must keep moving.

    Writing good documentation is a hard work. But it a necessary part of software development process.

    P.S> I really miss GW-BASIC Interpreter User’s guide documentation quality. I was able to understand each function usage from examples. I still have this book on my shelf near MS-DOS 3.3 OS manual ;o)

  25. AT: I’ll send that off to the UE guys so they know that that’s what you’d like to see.

  26. Duncan:



    * For regular expressions to be treated as an operator as the are in JavaScript and Perl.

    e.g.

    if (/w{3,6}-d+)/) {

    // do something

    }

    This would get rid of a lot of the unnecessary escaping of characters that goes on now.

    Did you know about @ strings? If you type @ before a string, then the only thing you need to escape in the string is the quote character. Hopefullt that will help you out.

  27. damien morton says:

    Enforcment of rules: FxCop will do that for you.

  28. Sean Chase says:

    Edit and Continue

  29. Stephen H. says:

    Priorities. I think the features which hold promise for shorter development times would be the ideal top priority. Once these features are pushed out the door, the job to further build up DevStudio will be hopefully shorter as well.

    This is common sense, but I would have expected some of the suggestions to be common sense as well, even if they lacked the specific detail as to what is bugging the user.

  30. Stephen: What features do you believe would hold the promise for shorter development time?

  31. damien morton says:

    Enforcment of rules: FxCop will do that for you.

    yeah – but I want Microsoft to follow the rules

    no more sealed classes

    no more designing dead-ends into the framework

    everything should be extensible, and/or composable, or replaceable

    Co/contravariance on interfaces.

    Explicit interface implementation is silly.

    Its an obscure workaround for not having the purity of co/contravariance.

    Generic collection classes – well organised please

    Like the C5 paper – a decent heirarchy of interfaces

    Now, once you get past IEnumrable and ICollection things get messy real fast.

    A layered approach is better.

    Functions in module scope

    You can use static methods to simulate, but sometimes its just more aesthetically pleasing not to have to prefix with a "namespace".

    Examples: Map, Reduce, Filter… so much nicer than Functional.Map, Functional.Reduce, Functional.Filter

    not everything is an object or a class.

  32. Cleve:

    8. Anything that VB has now that C# doesnt, like the My classes, named indexors, E&C, etc, (this is a general rant, MS says all languages are equal but this is not the case, if you add something to VB add it to C#, and vice versa. These two teams should really be merged)

    Cyrus:

    Why do you want VB/C# to be the same? If they were the same would there be any reason to pick one over the other?

    Me: :)

    I want to weigh in on this one. There should be _no_ reason to pick one over the other. This has somethign that’s griped me from the very start of .net. My background is both as a C/C++ programmer, and also a VB6 programmer. The last thing i was doing before .net came along was vb6 work, so it was more ingrained into my head at the time, so my .net conversion was to vb.net first – however, with my C background i have little trouble with C# either. To me, they’re the same thing, as i’ve heard so many people say – they should compile to the same thing after all.

    I can see a different need for C++.net, in that it’s got managed an unmanged in the one language – so fair enough.

    But really, what is the difference between VB and C#? As far as i’m concerned, you pick the language that looks nicest to you syntactically – AND THAT SHOULD BE ALL. Extra nice ways of doing things in C# is not fair on people who prefer the VB syntax – and extra nice ways of doing things is in VB not fair on C# people. Edit and continue is a classic example, VB6 had it, so it’s finally been put back into vb.net – but why didnt’ the C# guys get it? I see plenty of poeple here clamouring for it.

    The using statement is coming into vb.net 2005, but C# already has it…why didn’t VB get it at the same time?

    The difference i understand there to really be is that there are two different compilers – one for C# and one for VB. Why is this? They’re both doing the same job aren’t they? Taking a set of strings in a text file (the source code) and converting them to IL. Why isn’t there a whole hep of code reuse between the two (maybe there are, i havent’ researched this bit yet.

    95% of the time when i take an example peice of code that was written in C# and convert it to VB.net, all i have to do is take of the semicolons, rearrange the order in which variables are declared (int foo -> dim foo as int – a macro does that for me), and almost all i ever have to worry about. The only times i have troubles is when something is done in one language a completely different way in the other.

    There should be one compiler for VB and another C#, and they compile correctly, using the SAME OPTIMISATIONS, they only need a switch to test which language they are supposed to parse. Hell, by doing that, then the one assembly can consist of two *.vb files and three *.cs files, and it’d compile fine.

    This whole mini rant is subjected to my (current and unresearched opinion) that two seperate teams of people have write a compiler to support parsing

    if (x == y) {

    and

    if x = y then

    the possibilty exists (remote for this simple case) for two different sets of IL to be generated.

    In some places you don’t get a choice in what language you write in. I prefer VB.net myself, as it more readable (stop the flame war. I’m not saying it IS more readable, i’m saying it more readable TO ME). My current job is likely going to restrict all .net development to C# very soon. Technically, this doesn’t concern me as i’m actually comfortable in both languages, but … i feel like i’ll be missing out in the end. Yes, i’ll finally be able to do some of the things that are nice in C# that i couldn’t before (the using statement, for example) but i’ll be losing all the VB specific extras that have been done. In VS 2005 vb will have edit and continue, will finally have the /// documentation thing, will have the my namespace….i get shunted to C# by force, and i’ll have /// and …well…what else that’s productive for me? not edit and continue, no My, no taks list that’s always up to date.

    Now, some purists might say C# doesn’t need edit and continue (for example). I see a lot of people asking for it here, and i’m glad your response wasn’t ‘well, vb has that, go use it there’, but if people don’t want any particular feature, they simply don’t have to use it. make all niceities and features switch-off-able, and those who dont’ want it don’t get it, and those that do have a hell of a lot more choice. We’re all (VBers and C#ers) writing the same thing in the end aren’t we (compiled IL)? it’s never really appeared to me be so, even tho that’s what i’m told.

    C# people think that they have the best language, VB people think they do. But why? my choice came down to that fact that i don’t want semicolons cluttering up the readability…and that was all. why should i miss out because of that? Why should C3 people miss out on edit and continue and My because they prefer declaring the type before the variable name?

    Sorry for the long rant, and i guess it was just a rant without really suggesting anything and all i’ve really said is ‘me too!’ for cleve’s post, but i think it’s something that really should be considered.

    –Geoff

  33. Duncan Godwin says:

    Hi Cyrus,

    I do know about the @ with strings, you’re still required even then to escape the double quotes. I’ve done a lot of Perl and JavaScript and being able to just write the regex without worrying about escaping is far more natural and expressive to me. Also, if you look take a look at http://www.perldoc.com/perl5.6/pod/perlfaq6.html#How-can-I-hope-to-use-regular-expressions-without-creating-illegible-and-unmaintainable-code-

    you can see how comments could potentially be embedded making the regex self documentating. The biggest weakeness for me with regexes is often working out what

    they do again after you’ve written them :)

    So for me that’s the regex with as few character escapes as possible.

  34. Ron Buckton says:

    Although I think it is not likely to be added in any near-term release of C#, I would like to propose two language extensions for multithreading: "async" and "sync".

    "async" would be an attribute of a method declaration and would cause the compiler to perform a substitution of the method body with multiple methods which support asynchronous invocation, as follows:

    class Math

    {

    public async int Add(int a, int b)

    {

    Thread.Sleep(100);

    return a + b;

    }

    }

    would be:

    class Math

    {

    private class __AsyncAdd : IAsyncResult { … }

    public IAsyncResult BeginAdd(int a, int b)

    {



    }

    public int EndAdd(IAsyncResult ar)

    {



    }

    public int Add(int a, int b)

    {

    return EndAdd(BeginAdd(a, b));

    }

    }

    the "sync" extension would wrap a set of expressions similar to an anonymous delegate or a using statement like so:

    class Foo

    {

    public async void LongRunningProcess()

    {

    // Runs in async thread

    sync

    {

    // Blocks async thread and calling thread, runs in calling thread

    }

    }

    }

    I noticed that Whidbey/.NET 2.0 has some new features for thread synchronization and context switching that might make such a language feature possible, as well as useful to developers. Its a much cleaner implementation than asynchronous delegate invocation and with a built in language construct to handle synchronization might help those who need to post messages back to a UI thread w/o causing problems with the windows message pump.

    Any thoughts?

    Other than that, if you consider putting regex parsing directly in the language add x# parsing too 😉

    ron

  35. Doug McClean says:

    1. Support for pasting long string literals (SQL queries are the most common) and having them nicely formatted for me. It’s quite tedious by hand. There are some add-ins that help with this, but building it into the editor would be nice.

    2. +1 for covariant and contravariant return/parameter types.

    3. On the tuples issue, could it be supported by allowing generic parameter lists to be of variable length? E.g. System.Tuple<params T[]> (clearly that syntax needs work, but you get the idea) replaces Pair<A,B>, Triple<A,B,C>, and etc. This is a feature request for the runtime, I guess, but I saw tuples mentioned above.

    4. (not a request) Nice work on static types! Great idea, I never would have thought of it.

    5. (For version 3) I am working on some ideas about how the runtime could handle operators better, but they haven’t solidified in my head enough yet. I will be posting about them soon, and maybe try to implement my thoughts against rotor.

  36. How about making operators virtual and allowing them on interfaces?

  37. Doug McClean says:

    That’s definitely part of it (allowing operators on interfaces).

    Also, we need to distinguish between semantic and syntactic overloading, for things like concatenation operators which many people now put as addition operators just so that they can have a + sign in the language :). Incorrect semantic overloads like that kill any utility that having operators in interfaces could have. But it’s fine if C# treats + as a call to Addition if available, else Concatenation if available, else error.

    Support for defining your own operators would be very nice also. Intersection, Complement, Cross Product, whatever. I think the language could allow custom operators with a syntax something like this:

    // operators named Intersection and Union defined on Set

    Set a;

    Set b;

    Set c; // initializing these to something not shown for simplicity

    Set d = (a #Union# b) #Intersect# c;

    If no precedence heirarchy exists between operators for whatever reason (seems difficult to avoid in general when they are defined in different assemblies), then insufficiently paranthesized expressions are compile-time errors.

    I have more, but this is a start :).

  38. Doug McClean says:

    Oh, one more that is very high on my wishlist and might not be overwhelmingly difficult to implement:

    A serializability constraint for generics.

  39. Sherrod Segraves says:

    IDE

    * The IDE seems to have two modes: debugging and non-debugging. There’s one guy on our team who likes this, but the rest of us don’t like having to configure toolbars, panes, etc twice (and never quite getting them exactly the same in both modes). An easy way to save and load IDE preferences might cure this, and would make upgrading to a new machine easier too.

    * Better support for multiple monitors. Most developers at our company have dual 19" screens, for a desktop of 2560×1024. My machine has three 21" screens, for a desktop of 4800×1200. In MDI mode, the IDE insists on opening windows to nearly span my entire desktop, so I have to resize everything after I open it. How about a sanity check of 1200 pixels wide for new MDI windows? In tabbed mode, I want two side-by-side panes per monitor, or some way of making panes snap to an immobile grid. Instead, the panes keep shifting around, and need to be tweaked to keep them in place. Also, the IDE sometimes gets in a funky mode where the splitters between panes can’t be moved.

    FORMS DESIGNER

    * Get rid of (or let me turn off) accidental double-clicking in the designer causing the addition of an event handler. It seems like every other time I open a form, Visual Studio thinks I double-clicked, and I get an unwanted form1_Load or panel1_Paint event handler.

    SOLUTION EXPLORER PANE

    * Let Alt-M, Alt-O collapse the Solution Explorer pane’s treeview. We’ve got 75 projects in our solution now, and manually collapsing all the projects in Solution Explorer is a pain.

    EDITOR – #REGION

    * Standardized regions would be nice – #region Data, #region Properties, #region Event handlers, or something like that

    * Regions should be automatically collapsed when I open a code window. Either that, or save the expanded/collapsed state of the regions.

    * The state of regions being expanded/collapsed should be part of the view, not the document. For example: I open two windows for a document, find the method I want to see in the first window, then go to the other window and automatically hit ALT-M. ALT-O, which makes me lose the view of the method in the first window. Aaargh!

    EDIT AND CONTINUE

    * It’s a big-ticket item, but it would help. On my old machine (2GHz, 500MB), a low-level code change would take over 10 minutes to compile. On my new machine (3GHz, 1GB), it’s only 1 minute, but edit-and-continue would still help, especially when working on custom controls where you really need to see the visual results of tweaking.

    * Not really edit-and-continue, but when changing a custom control, the designer often won’t show the changes, even afer a full recompile. One cure is to close and re-open the solution. Another is to make sure that all designers are closed before compiling, but that’s easy to forget.

  40. I want haikus to pop up randomly to help me think. They could either be off-topic in order to inspire me or they could be related to what I was typing at the moment. Like if I’m writing a for-loop and I don’t make the end-condition correct, it could go:

    infinite spiral

    your code descends to madness

    change value of i

    Or maybe it could serve an entirely different purpose. Maybe it could figure out when I’m writing a haiku (similar to what you’re proposing for regexps <a href="http://blogs.msdn.com/cyrusn/archive/2004/06/20/160788.aspx)">here</a>) and offer up domain specific information that would change as I type. What do you think?

  41. tuesdayscoming:

    Sounds to me like you you want Clippy for VS?

    Hi, it looks like you’re writing a virus? Which snippet do you want?

    a) Buffer over flow.

    b) RPC exploit.

    :)

  42. Orion Adrian says:

    Do analysis on the color people use for strings. I’ve used red for years and I know a lot of people who do as well. It’s just one of those things where you want it colored since it’s so easy to miss an end quote otherwise. If strings are red, then you’ll never miss it.

    (Probably another group)

    I want auto-formatting profiles. Rather than having to change my auto-formatting settings each time I want to modify a document, I’d just like to be able to choose a profile. This is especially important for all XML-based documents.

    Import/Export Settings – But I want to be able to choose categorically what I want to import and export and of course it would have to be intelligent about it since there may be settings that work on newer versions, but don’t work on older versions (yes I want this cross-version compatible). External tools are ok.

    A dockable tool that shows all the key combinations available and will filter the list appropriately once you press the first part of a chord.

    Orion Adrian

  43. Aleksei Guzev says:

    Generating makefiles +1

    On formatting.

    Opera treats a mime message as XML document. I.e. headers are treated as XML elements, Body is treated as another element. Thus a user can write simple CSS describing desired formatting for the message on screen. But it could be be too much for a good thing 😉

    I have metioned how much do I like anonymous delegates as iterator blocks? But the syntax is too complicated. I do understand, that there are reasons for this, but the coplexity will scare some people.

    Will it be possible to run the block on another thread. Automatic synchronisation in this case will be a marvellous feature.

    And, finally, you know it’s not so easy to hummer articulations for the velleities out.

  44. Aleksei: Not sure what you’re discussing with the XML/CSS thing. What would you like?

    Luke and i were talking about this for anonymous delegate syntax:

    optional_parameter_list block.

    so you could write:

    public int Count {

    get {

    int count = 0;

    this.Iterate({ count++; });

    return count;

    }

    }

    instead of:

    this.Iterate(delegate { count++; });

    I find the delegate keyword very heavyweight. Oh well…

    And yes you can run the block on another thread.

  45. Doug: Would :

    where T : ISerializable

    be good enough?

  46. Aleksei Guzev says:

    XML/CSS would provide a way of syntax colouring of C# code. But it’s a thought spoken aloud rather than a wishlist item.

    On delegates.

    Those parenthesis look strange. In ruby one writes

    range(1,1e50).Iterate( 2 )

    {

    x| sum += x

    }

    instead of

    range(1,1e50).Iterate( 2, delegate(x)

    {

    sum += x

    });

  47. Doug McClean says:

    Cyrus,

    No, unfortunately it isn’t. Ooodles of types are serializable but not ISerializable (examples: System.String, System.Int32, the vast majority of my serializable user defined types). I need to constain based on the serializable bit in the metadata, so that I know if I can actually expect to be able to serialize something. ISerializable is only if a type needs fine control over its serialization.

    Scenarios:

    1) I have an IEntity interface for my business objects that returns a key that can be used to retrieve them. It’s great and it enables tons of stuff in my data layer and elsewhere. IEntity<K> will be even better, but only serializable types can be keys, because I have to know that I can persist them to disk or send them over the wire. The most common key types are Int32, Guid, Int64, and String, none of which is ISerializable.

    2) It seems to me we need this constraint in order to mark generic types with fields typed as a type parameter as serializable:

    [Serializable]

    class Example<T> {

    private T _someThing;



    }

    doesn’t really seem like it should work without where T : serializable or marking _someThing as [NonSerialized]

    What do you think? I think this is a critical feature for generics, but I haven’t seen it addressed anywhere, so I don’t know if someone has this on their radar or if I am just missing something or what.

  48. Aleksei: The parenthesis probably look strange because you’re used to Ruby. I find the idea of a block just floating around not as an argument to be extremely disturbing. That said, I also find the use of the word "delegate" to be way to heavyweight.

    I’d prefer something like:

    range(1, 10).Iterate(2, (int x) { sum+= x; });

    I like that syntax because it’s very analogous to how you write out an actual method like:

    Add(int x) {

    sum += x;

    }

    Except that you haven’ written down ‘Add’. The use of would be to help disambiguate the parameter list from our horrid cast syntax.

  49. Doug: I see. I can give you a suggestion but I’m not sure if you’ll like it.

    public class Entity<K> {

    static Entity {

    if (typeof(K).GetCustomAttributes(typeof(SerializableAttribute)).Length == 0 && ! typeof(K).InheritsFrom(typeof(ISerializable)) {

    throw new YourException("You can only instantiate with a type variable that is ISerializable or has the SerializableAttribute on it");

    }

    }

    }

    Yech… but it kinda works.

  50. Aleksei Guzev says:

    But this is not analogous to how you write an actual if, for, foreach statements. Anyhow You should keep on Your way.

    Yes. I like Ruby and wish to see something like on .NET. I do not wish C# to become Ruby. But sometimes I need a feature.

    Classes or Types are obects themselves. Maybe I don’t know all the tricks… Is it possible to create my own class of classes. For example, providing a virtual class method? C# would not allow creating virtual static members.

  51. Aleksei: Ah, I see. That’s interesting.

    Can you give me an example of what you mean by "create my own class of classes" or an example of a "virtual class method". How would that work, what would the benefit be? What would you be able to do with that that you currently can’t do with C#

  52. Doug McClean says:

    Exactly. Yech. I agree it kind of works, that’s my current plan, and backed up by an FxCop rule it will be a decent workaround, but I think it is sufficient motivation for adding a serializability constraint. Especially since the syntax extension is minimal.

    Drawback to my suggestion:

    Serializability of A does not guarantee serializability of B, when B : A. Hence, even the constraint is not an iron clad guarantee of serializability (unless combined with a value-type constraint, I guess). I will ponder the implications of this.

  53. Orion: Import/Export is something that the VS team has been working hard on for 2005. Fine grained control of that is a large part of it as well.

  54. Damien:

    "Enforcment of rules: FxCop will do that for you.

    yeah – but I want Microsoft to follow the rules

    no more sealed classes

    no more designing dead-ends into the framework

    everything should be extensible, and/or composable, or replaceable"

    Do you have example I can send to the BCL team?

    "Co/contravariance on interfaces.

    Explicit interface implementation is silly.

    Its an obscure workaround for not having the purity of co/contravariance. ": Agreed. Although I need to investigate a claim from the mono team that ExpIntImp is more powerful and Co/Contra is a subfeature

    "Generic collection classes – well organised please

    Like the C5 paper – a decent heirarchy of interfaces

    Now, once you get past IEnumrable and ICollection things get messy real fast.

    A layered approach is better. "

    Did you like the C5 paper? I wasn’t a really big fan of the hierarchy they proposed

    "Functions in module scope

    You can use static methods to simulate, but sometimes its just more aesthetically pleasing not to have to prefix with a "namespace".

    Examples: Map, Reduce, Filter… so much nicer than Functional.Map, Functional.Reduce, Functional.Filter

    not everything is an object or a class. "

    Why would Map/Reduce/Filter be in the global interface and not on the list interface?

    I.e.

    public interface IList<A> {

    IList<B> Map<B>(Function<A,B> f);

    IList<A> Filter(Predicate<A> p);

    etc.

    }

  55. Doug McClean says:

    Haha, oh no, not this again! :) See the thread about what belongs in an interface for my answer to that question.

  56. Doug McClean says:

    Oh, and in regards to this:

    ""Functions in module scope

    You can use static methods to simulate, but sometimes its just more aesthetically pleasing not to have to prefix with a "namespace".

    Examples: Map, Reduce, Filter… so much nicer than Functional.Map, Functional.Reduce, Functional.Filter

    not everything is an object or a class. "

    Why would Map/Reduce/Filter be in the global interface and not on the list interface?"

    I seem to remember a suggestion for extending using to allow:

    using System.Math; // name a static class instead of a namespace, and the methods of that class can be used directly

    Possibly a good idea, since I don’t know about moving those methods themselves to the module level, especially in the System namespace, just so that they can be undecorated. Especially since people are so likely to want to reuse those names for other things.

  57. Geoff: C# also has unmanaged code in it. Would you merge that into VB as well? I don’t see that being something VB would like.

    I see the 3 languages targeting different types of developers with different needs. The features that each provide were decided by taking their respective users and deciding what they would find most useful for the next version. Note: E&C was proposed to C# users and the feedback we got what that while people wanted E&C they said they wanted refactoring more. VB did the same but found that its users wanted E&C.

    The languages are also not the same. Things like iterators and anonymous delegates and nullable types are areas where C# moved forward based on the type of work that our customers do, whereas I think that VB looked at them and decided that it’s customers wouldn’t benefit from it in the same way.

    I can’t talk about our internal code or how much is shared.

    However, at no time did we ever say "no one wants E&C". Instead we asked ourselves "given the time and number of developers we have, what can accomplish in the whidbey timeframe?"

    There’s a lot more I could tak about, but I’d like to hear your feedback on this

  58. Doug, I like the idea of "using" a class and getting access to the statics in it. Definitely worth looking into.

  59. Cleve Littlefield says:

    Cyrus: What interface would you like to see the refactoring API expose?

    Well, not really sure how that would work, but I am sure that if there was a moderately easy to use interface into this engine, and the resulting UI (list of changes that will be performed), eventually some tedious situation will just call out for a custom refactoring would integrate right into the list of current refactorings. Plus factoring this into an API would be good for you too, then you dont have to be in the business of coming up with new refactorings all the time, and can leave it to third party tools.

    Cyrus: What would C# macros get you over running things through a C preprocessor? What power are you missing today that you think macros will get you?

    I want the full power of the .Net framework and the language I work in everyday. For that matter this should read (any .Net language) not just C#. I can imagine things like kicking out to a web service to get data for the macro to use. (Always good to prove a point by bring in a MS marketing focus, right?)

    Cyrus: Why do you want VB/C# to be the same? If they were the same would there be any reason to pick one over the other?

    I believe Geoff stated this perfectly. He likes VB, I like C# because I grew up with C++ and I hate the extra typing. There shouldnt be any penalty or feature envy over my choice, you just keep the religious holy war fires burning! I also agree that there should just be one compiler that you guys use, with different parsers feeding into "the one compiler to rule them all".

    While I am at it, a few more suggestions…

    1. A way to customize all code that VS generates in any situation. Like the default event handlers, I hate MyButton_ClickHandler, and would rather see OnMyButtonClick.

    2. Give me the option to not open the Component designer by default for component files. I never use (and dont think any advanced programmer does) this view.

    3. A preview kind of like your refactoring preview for Find and Replace. Show me all the lines that match so I can remove the few odd ones that arent true matches and commit the rest.

    I would like to say great job on the features that are coming in VS2005 already, a lot of us our drooling for this release.

    Finally, you think you can post a site somewhere with all these feature suggestions with a voting mechanism? You might get better feedback that way…

  60. Aleksei Guzev says:

    If I understoond Your question, I cannot give an example.

    But on the other hand it’s possible to emulate virtual instance methods through reflection. It’s what do I now to emulate virtual class methods. I simply declare static methods and obtain their infos through reflection. Performance issue.

    Why does C# provide virtual instance methods while the same behaviour could be achieved without new syntax rules?

    What about restricting methods taking Types as arguments to receive only a limited set of types?

  61. Sorry Aleksei, I’m just not getting it :(

    Can someone help me understand the issue?

    C# already has virtual instance methods. But I thought I say you mentioning virtual static methods above. If that was the case then I couldn’t figure out what that would even mean and I was hoping for an example to show how it would be useful.

  62. Cleve: I see what you two are saying, and it’s something we’ll look heavily into in the future. (I’m completely serious too, this isn’t a blow off). As I said, it’s quite difficult given the different capabilities and goals of both languages

    I agree with you on code gen. It’s something we need to do better at in the future. You should always have some way to control what’s generated.

    I’m still not sure what you mean by a macro yet. Can you give me an example?

  63. Aleksei Guzev says:

    …And one more reason.

    As I see in hierarhy tree System.Type is an abstract class. Is not it a class for classes?

    Developers of the .NET needed a class of classes for some purpose 😉 Why others will not need somethign like this?

  64. Aleksei: I think i may be understanding what you’re talking about (but please correct me if I’m wrong). Would you like the ability to dynamically create a type at runtime? I.e. create a new Foo class and add a method to it and have it implement the IFoo interface programatically? You could then pass a new instance of that type to someone who wanted an IFoo and they’d be able to use it.

    If that’s what you’re talking about then you might want to look into the work that the Iron Python guys have been doing with strong dynamic languages.

    It’s possible to use the same APIs from C# however, the language ddoesn’t give you any special support for doing that. Is that what you’d like to see in the future? If so can you give an example of what you’d like to see?

  65. Cleve: Finally, you think you can post a site somewhere with all these feature suggestions with a voting mechanism? You might get better feedback that way…

    Excellent idea. It might also help me bone up on my webdev skills. I’ll try to get all these ideas written down this week and put up as another post for people to look at. Then if there are more ideas they can be added to that.

    That way they don’t get lost within the 100 posts that have followed so far.

  66. BillT says:

    I agree with Geoff and Cleve that VB.NET and C# capabilities should be identical. It makes no sense to me to create features (for either language), and not roll that them into both languages. The job of converting from one language to the other should be just a click, not a human-programmer task.

    As to the "3 different types of developers with different needs", it would be great if Microsoft were to think of that as 3 different views into the same development environment, instead of three different development environments in the same IDE. The 3 types of developers model is at best theoretical. Many programmers do not fit well in such a model. The model’s just an invention, not a reality.

  67. Robert Jeppesen says:

    +1 on the VB.Net/C# differences. I also want the My namespace. Perfect for tossing up quick prototypes, but I really like my semi-colons as well. I don’t see why I can’t benefit from this feature in C#?

    I agree with BillT. I am "a different type of developer" depending on which time of the day you ask me.

  68. BillT: If switching between programming languages should be just a click, would you like to see that extended to managed c++, to ocaml, to lisp, to python, to perl, etc.?

    Would you like us to provide this common language infrastructure that all other languages could plug into and interoperate with?

    BillT: I never claimed there were 3 different types of developers. I claimed that there were 3 languages that were designed to be target the needs of different types of developers in different ways. What is beneficial for one type of developer is not beneficial to another.

    For example, there might be some VB programmers out there that might want to do pointer manipulation and unsafe code, but the vast majority do not (if you don’t beleive me just ask them). Should we bring VB up to parity with C# in that regard?

    Sometimes we get parity because we believe that there is a feature that both camps would want (partial types, for example). But other times we consciously do not have the same feature set because it is not the case that it is beneficial to the majority of users. And this is one of those cases where if you’re not beneficial you can be detrimental. You add to the complexity, you add to the learning curve, and you can end up with a bloated language at the end that attempts to do far too much and which no ones really likes using.

    The purpose of .net (IMO) is to allow a platform where all these langauges can talk to eachother. Not to allow a common syntax where you can flip a switch and your C++ becomes VB, or your perl becomes scheme.

    You pick your language with the knowledge that it will have strengths and weaknesses. A series of tradeoffs. Often times I look at other languages and I ask why it’s so difficult to accomplish the same task in C#. But then a bit later I’ll have the reverse reaction.

    Rather than just making one uber general purpose language that tries to be perfect for everyone (and will probably fail given the long history of languages) we instead go for individual language route.

    Another example might be helpful. We added anonymous delegates to C# 2.0, but not to VB. I believe that adding them to VB was viewed to be a large amount of work for very little benefit to most of VBs customers. Remember that in this case this could be detrimental. VB customers might ask "what the heck is this. I don’t understand, and now I see this code that makes no sense to me. Why did you change a perfectly good language to add this useless complex feature." Now, also factor in all the requests in this thread for edit and continue. The two features are not independent. Making edit and continue work within an anonymous method would not be a trivial task.

    So, we could have taken the route of "lets and anonymous methods and edit and continue to both languages" and then potentially not been able to complete either because of the high cost. Or we could say "VB adds E&C but no anonymous delegates because they can finish that in time" and "C# add refactorings and anonymous delgates, but no E&C because they can finish that in time".

    If you do want language parity, then that might come at a cost. Both in customer dissatisfaction ("why are you screwing up my language will all these things I don’t want") and in limiting the number of features that we can provide ("we can’t add both foo and bar, because making them work together will take more time than we have").

    Now, if you find out later that in fact your customers do want such a feature, then you take that feedback, you re-adjust your schedule and you try to figure out a way to get the best feature set for them in the limited time you have.

    This is why VB added support for things that C# had in the last version. But it’s also why VB won’t add things that C# has _because_ the feedback has been "we don’t want it" or "we’d rather have this other feature instead".

    Note: this is why I’m asking for feedback and what people want here. If we overwhelming hear from people that they want something that VB/SomeOtherLanguage has then we will absolutely take that into account.

    So if we got tons and tons of feedback that people wanted VB/C# to be the same except for syntax, then it’s something for us to look at. Is that something that people want?

    For example, would people rather have had us get parity with VB with E&C. Or would they have preferred the new language features and refactorings? I would really like to know.

  69. Aleksandar says:

    It is more a Visual Studio request… I would like to see something what I miss since old DOS days and my trusted TSE editor – better incremental find feature. In addition to Ctrl + I + typing, I would like to have dialog that pops up on keyboard shorcut, with small edit control on top, and list box below that contains content from the current document. Every change in edit box cause list box to change content, and show only lines that contains typed string – similar to current Incremental Find. Up/Down arrow keys can be used for list box navigation, Enter or double click for goto-to-selected-line command. Simple as that.

    apetrovic AT teletrader DOT com

  70. Kavan says:

    Another +1 for VB.NET/C# having the same functionality when it doesn’t compromise the language. At least properly support optional parameters and named indexers/properties with parameters. I want C# users to be able to consume VB.NET dlls without the trouble they get now because of lack of support for this. You don’t have to add support to create this functionality in C#, just add support to consume it. At least properly consume CLS-compliant code, that’s all I’m asking.

  71. AT says:

    Crazy idea.

    Attributes on local method variables and code blocks in addition to classes, class members and method params.

    For example if method declare multiple local variables and work with them. It’s impossible to assign attributes to local variable, only to method params.

    This make it’s some-that hard for custom FxCop rules to work with method control flow at IL level – they have to analyze comments in source code to get additional information about local score data and programmer intentions

  72. Ron Buckton says:

    Am I off base with the whole "async"/"sync" language extensions? I’ve noticed no one posted a comment at all.

  73. Jim Arnold says:

    "What would you do with the managed API? (Seriously, I want to know :-) )"

    Specifically, write a code style enforcer. FXCop is great, but it works on MSIL, not source code. It would be sweet to be able to parse C# files into a CodeDom tree and run check on that. I can think of other applications too (testing the output of a code generator, for example).

    "Virtual by default: You can get this with an FxCop rule now."

    Yeah, but first-class support would be nicer. Classes aren’t sealed by default, so why should methods be?

    "We’re always trying to balance simplicity of work with density of syntax. is "new int[] {1,2,3}" too much clutter for you?"

    It just seems weird that I can do:

    int[] numbers = {1,2,3};

    but I can’t use the same syntax for inline instantiation.

    Jim

  74. Orion Adrian says:

    1) Integrate more C-Omega stuff. (Like, ?, +, *, !) and inline XML and inline XPath

    2) Declarative restrictions that automatically throw exceptions for me. (See Eiffel)

    e.g. If a number has to be between 1 and 100 (say an index), I should be able to say

    object this[ int index ]

    [ check( test, exceptionConstructor() ) ]

    [ check( test, exceptionConstructor() ) ]

    {

    }

    This could eventually be expanded to something truly declarative like:

    index inrange 0 to N

    index nonnegative

    which could give warnings or errors when the invariants aren’t met.

    I miss const :(

    Orion Adrian

  75. I’d like to see the new VS.NET Team Edition support the provider model for source control and unit testing.

    Thus I could switch the unit testing built in with NUnit for example. I realize that it might require tweaks to NUnit, but in principle , NUnit (or mbUnit) would be a provider for unit tests.

  76. Kristof says:

    Generic properties where you can specify the returned type. It would be nice if you could do the same thing as with generic methods.

    class MyClass

    {

    public T MyProperty<T>

    {

    get;

    set;

    }

    }

  77. Ron: Async/sync. I’m digesting. That one needs a lot of time for me to wrap my head around it :-)

  78. Orion: Integrate more C-Omega stuff. (Like, ?, +, *, !) and inline XML and inline XPath

    See my later post on how I think we could do this better rather than having one uber laarge language that tries to do everything :-)

    Which method do you prefer?

  79. Ron says:

    Cyrus,

    I think the language parity for VB/C# gets a lot of play for a variety of reasons. One of them that comes to my mind has to do with how VB6 programmers were generally seen as "playing around in a toy language". The last is a direct quote I received on a previous project. This despite the fact I could code circles around the guy in C++ and knew the ins-and-outs of COM far better than he ever would.

    I’ve spent most of my time in C# over the last year and a half. I expect I’ll continue to work in C# (with one exception I’ve just started in VB), but only because I want to avoid the lame commentary on the part of narrow-minded developers.

    As for features, I agree with the other comments about Edit and Continue. This would be a very welcome addition.

  80. Cyrus & Cleve:

    You are probably talking about macros like these one

    http://nemerle.org/macros.html

    Fully extensible compiler plugins, which can also extend language syntax, algorithmically traverse object model of assembly adding inheritance relations, methods, classes, inlige algorithmically generated code at any place

  81. Ron: Thanks for the explanation. I’ll keep that in mind.

  82. Orion: Const is useless.

    J/K!!!!!

    I would love const too. I understand that we’d need to do work with the BCL. But I think we should do it because it’s so beneficial _and_ because it would help us find bugs with our existing code. I’m sure that adding const would reveal these problems and would prevent futures one from coming up, so I see it as being worth it.

  83. Aleksander: XCode has a similar feature (with incremental find). It rocks. I want it in VS.

  84. AT: "Crazy idea.

    Attributes on local method variables and code blocks in addition to classes, class members and method params. "

    Not crazy at all :-)

    Incredibly powerful and could allow people to do some pretty awesome compiler integration.

  85. Cyrus, Cleve, etc:

    To be honest, i’m very on the fence about this, especially since reading your long post on this, Cyrus.

    I can certainly understand your point of view, and agree with it partially, but i can’t help but feel like it’s still letting some people down.

    One of my biggest problems is that i don’t know any ‘just vb coders’. My story (short long form in order of usage) goes: Pascal, C, C++, ins and outs of ATL and MFC, VB6, C, PERL, Java, PERL, C, VB6, C++, VB6, .NET. Every other developer i actually know in person has a similar background to me, so i can talk pretty much any language i like, and they all understand. I can read pretty much any language now, and even if i don’t know it, it’s readable and i can understand what it’s doing.

    There has been one hell of a stigmatism placed on VB6 programmers. It’s never been respected as a ‘programming’ language, and any peers a VB6 coder has will often look down on them. With the advent of .net, this hasn’t gone away. C# got some very powerful language features, and what did VB get? edit and continue and the My namespace. (yes, i’m exaggerating). But continuously it seems that VB gets stuff to make things ‘dumb and easy’ (when viewed from the outside) and C# gets sophisticated improvements.

    I’m sure you’ve heard this whinge time and again. You voiced concern over adding complexity to a language that no one wants. Given this case tho, what about the changes to VB that are coming in with whidbey? Operator overloading is going to go a long way towards scaring us dumb VB6 guys. Now that operator overloading has arrived, VB has essentially become C++ without pointers – just a different syntax, and without the hassle of #include. I really (for example) how anonymous delegates are going to scare a vb programmer when they’ve already got to deal with the other parts of the language that have already made vb just as complex in different ways to c#.

    You asked about the other .net languages, but i see these as a little different. Any .net language that was not developed by MS, well, they have to support themselves. C++ is a different beast altogether, and can happily sit out on it’s own (the way i see it, C# is managed that can access unmanaged, while C++ is unmanaged that can access managed. This is a very general view, but ..). J# is a waste of time (IMO), and can be thrown away :)

    VB and C# are, as i see it, the same thing written twice, by two separate entities. Sure, there’s some differences between them but do they have to be standalone separate things?

    Just merging the compiler into one that handles both i see as a tremendous improvement (and solution to it all). Write function X in C#, function Y in VB, and you can exploit the features of both languages as you see fit. This is coming closer to reality already – you can compile different assemblies in different languages, and if the concept of partial classes could cross assembly bounds, then we’d almost have it – but merging the two languages into the one assembly would solve almost all my issues.

    I’m stopping now as really all i’m doing is stating opinions that generally aren’t that well researched, and for the most aren’t saying anything new. So i’ll just leave it at a wish for closer binding between the two fully MS supported .net languages. I’d happily never complain again that ‘C# has this, VB has that, why didn’t the other get them?’ if i could write a method that looked something like:

    Public Function DoStuff(Optional Foo as String = "foo")

    Dim X as int32 = 0

    Dim Y as String = "47"

    <something here to mark a switch to C#>

    X += (int)Y;

    <end C# area>

    Return X

    End Function

    If you get what i mean….Yeah, i know it’s a big ask, but without making either of the languages super complex (which was a large point of your response) the ability to switch willy nilly will make a large number of the people that want both happy….wouldn’t it? I know i would be ecstatic :)

    I dont’ really see it as that hard provided the one compiler for both languages…but of course i’ve never written a compiler either :)

    –Geoff

  86. Kavan says:

    The ability to use several programming languages inside the same assembly is indeed a long term goal I would try to achieve. Yes, .NET has made it possible for several languages to "communicate", but when you want to have two classes that each reference the other you’re out of luck. You have to create them in the same language. And I’ve come across several cases where I had to compromise structure of the solution because of this. If this would be possible then I’m completely for the idea that VB.NET and C# have different functionality. Until this is possible I’d like them to have similar power.

  87. Kavan: Excellent point. I’d never considered that.

  88. Geoff: I’m going to have to fish out my senior thesis. That’s exactly what it could do (switch between languages like java/perl/etc. 😉 )

    I’m not going to rant anymore because I want to hear other opinions on this. However, we do have strong beliefs on this. If we make languages the same then suddenly C# cannot move without thinking about what VB developers would think of this. What if we want to add more features that most VB users absolutely hate?

    The things that Orion/AT have suggested could fall into that camp. New operators like !+? appearing all over the place (or in vb adding new strange keywords like "OneOf" or "OneOrMany").

    By making the languages the same, we can no longer move in different directions, (which we’re already doing) and which we thing would be the best thing for most of our users.

    Note: Not all of users, just most. I do _not_ believe that there is one language to rule them all. I see there being many languages with differetn strengths weaknesses, and a good programmer will be able to pick them up and use them well to solve the problem at hand. It’s the old saying about a carpenter and his tools all over again.

    Again: I want to assure you, if our users to end up wanting something badly enough and canshow justification as to the benefit they would recieve, then we will add a feature. It may come a version late, but you end up with languages that have features that benefit everybody but without features that most of the developers don’t want.

    I.e. a central core that is very similar, but with other features there that you see when you go beyond the surface that make the languages very different.

  89. damien morton says:

    "Enforcment of rules: FxCop will do that for you.

    yeah – but I want Microsoft to follow the rules

    no more sealed classes

    no more designing dead-ends into the framework

    everything should be extensible, and/or composable, or replaceable"

    Yeah, peeve of the day: XmlAttributeOverrides. I _want_ to generate my overrides as they are asked for. As it is, I have to traverse over 20-30 large assemblies reflecting on the types and members therein, building a way-overly large set of XmlAttributes.

    XmlAttributeOverides.Item in non-virtual, so theres absolutely nothing I can do. Its not a show-stopper, but its a fine example of what could be safely user-hookable, but instead turns out to be a dead-end requiring a work-around.

    Ok, so this isnt an example of the "sealed" problem, but it is an example of a bunch of methods that could belong to an interface or be declared virtual.

    Let me modify my rule…..

    Every public method must be declared virtual unless it is also declared as patr of an interface.

  90. Damien: agree 100%. Actually, scratch that. I agree 1000%.

    I can’t stand it when i run into that exact same issue.

    If it helps, my code only passes around interfaces so you’re free to do whatever you want. This often times involves me taking BCL types with no interfaces, and creating an interface an a wrapper class that implements that interface that will then call into the underlying BCL type.

    We call them ThinWrappers and I hate having to do that. But it’s the only way to get things to work sometimes. Sigh…

  91. damien morton says:

    Oh, and your propsed syntax for delegates is great…

    EventHandler foo = (object sender, EventArgs e){ return x; }

    sweet!

    Its the similar to a syntax I proposed for python string interpolation a while back:

    python allows for this:

    a = 1

    b = 2

    "%(a)s %(b)s " % locals() -> "1 2"

    The python team was casting around for a syntax that allowed arbritary expressions:

    "(a+b)" % locals() -> "3"

    Consiseness _should_ be a worthy goal.

    Actually, that was one of the other nice features of the nice language; the block syntax for method calls: http://nice.sourceforge.net/manual.html#blockCall

    (loosely translated into c#)

    //First define the method we’re going to call:

    //Like an ‘if’ statement

    void when(boolean condition, block VoidHandler action)

    {

    if (condition) action();

    }

    //Now exercise our method with block syntax:

    void main(String[] args)

    {

    when(1 > 0)

    {

    println("Math is working correctly!");

    }

    }

    Note that we could just as easily have written:

    when(1 > 0, delegate {

    println("Math is working correctly!");

    });

  92. Orion Adrian says:

    Support for the object type in the XML Serializer

    Also, if I want to serialize a class, but not deserialize, I still have to write set properties for all the properties I want to serialize. It will only work with public fields and properties with both get and set operations. That has been problimatic enough that I had to abandon the XmlSerializer. I shouldn’t have to rewrite my class to accomodate the XmlSerializer.

    Also fix the inconsistency with XmlRoot versus the methodology for declaring other types of element. Declaring the name of the root element along with its namespace should be part of the constructor. That way, any class can be root without having to worry about declaring it to be so.

    Orion Adrian

  93. Orion: Can you give me an example of when you would want to serialize something but not deserialize it?

  94. Orion Adrian says:

    Also I’d like an intrinsic store for properties. I don’t know how many times I have to write:

    type x;

    public type X

    {

    get { return x; }

    set { (if value is ok) x = value; }

    }

    What I’d like instead is to not have to write the

    type x;

    Instead I’d like to see a merging of fields and properties. One major use for properties is to provide constraint checking to fields. This could be done in a more direct fashion. Something declarative would be nice.

    [Range: 0 to 10]

    public int X;

    or using the existing Attribute syntax:

    [RangeRestriction( 0, 10 )]

    public int X;

    Also any method that uses a property should use a field. I’ve found quite a few instances (can’t remember off the top of my head, it was awhile ago) where I was working on something and the native method would only work with properties, not with fields.

    Orion Adrian

  95. Orion: I’m not sure what you mean "any method that uses a property should use a field" could you explain a bit more.

  96. Orion Adrian says:

    Cyrus: Sure… let’s say I want to create an XML log. I don’t need to read in the log, but I need to write it out.

    Also if I want to serialize something like the size of a collection (say it’s very large and that information would be useful without having to parse the whole thing).

    Basically anything that’s computed rather than stored doesn’t have a set property, but I still might want to serialize it.

    Orion Adrian

  97. Orion Adrian says:

    Cyrus: Basically, in my mind a property is just a fancy field.

    I should, and often do, create public fields when I don’t have any restriction checking to do on it. But I get hit by the few methods in the CLR that only operate on properties.

    Properties should be a way to

    a) add restriction checking

    b) abstract the data store

    So if I need neither, I can go ahead and use a public field. It’s nice, tight code. So everything that works on properties should also be able to work on fields.

    Orion Adrian

  98. INteresting. I think of a field as a dumb property and a property as a dumb method.

    Objects are nothing but methods to me. None of thie field/property crap :-)

    I do agree taht that sort of weird disjoint between fields and properties would be nice to clean up.

  99. Darren Oakey says:

    hmm.. I am preparing my list of feature requests (imagine a manic grin and ringing hands :))….

    but

    I’m wondering what you guys who are saying "vb/c# should support the same features as vb/c#" are on? WHY?

    if vb and C# are functionally equivalent, then we achieve exactly one thing by having both of them –> increased pain. You don’t just have to know one language, you have to know two. And there are NO benefits. It’s not like C# is hard to learn – pick one, and use it! It’s not like you can’t write something to port legacy code to C# – it’s exactly as easy as porting it to VB – if you make them the same, then throw one out!

    However, am I arguing for that? NO! I program mostly in C# now. I used to compete in assembler. I’ve over 10 years commercial experience in C++ – yet I LOVED VB – used it for years, and enjoyed it.

    Why? VB was simple. VB was quick. It was one step away from a scripting language – you could even make changes when you were editing. It had no inheritance, but it had interfaces, so you could make an elegant well designed object structure, but not worry about carrying along baggage. It had one of the most wonderful things in the world – binary compatibility! – An actually compiler level guarantee that your external interface hasn’t changed! I’d pay a lot of money to have that back again!

    IMHO when MS created VB.Net they screwed up BADLY. C# was a beautiful compromise language – features and power. They did NOT need to ADD features to VB. They needed to take them away. They needed to make VB even simpler. They needed to Add better integration libraries like "ExecuteAndWait" "Send Keys to app" – etc. They needed to target VB exactly where it should be, which is

    a) simple quick, and absolutely rock-solid single purpose apps

    b) integration apps using com/screenscraping/services whatever to connect and control

    c) "scripting" type apps, with all of VB’s UI dev power thrown in..

    They are going that way with namespaces like "My", but it’s not enough. Unless they pull things like inheritance out of the language and go in a different direction to C#, in my mind VB.NET is just a perfect case study example for the pro-euthenasia among us.

  100. Darren Oakey says:

    oh… and maybe my hands are wringing :)

  101. Aleksei Guzev says:

    Cyrus: the example is too long. Should I post it here?

    mailto:aleksei.guzev@bigfoot.com

  102. JimG says:

    Ability to define fields within properties, so instead of:

    type x;

    public type X

    {

    get { return x; }

    set { x = value; }

    }

    you could type something like (lots of options for different syntax here of course):

    public type X

    {

    store { type x; }

    get { return x; }

    set { x = value; }

    }

    or just:

    public type X

    {

    type x;

    get { return x; }

    set { x = value; }

    }

    There are some fields that are so linked to the property definitions that they should syntatically liked to the property. I accomplish the same thing in my code now by wrapping the field and property in a region but it would be nice not to have all that extra stuff in the code.

    Also, there are many times that I create public read, private write properties such as:

    protected type _x;

    public type X

    {

    get { return _x; }

    }

    then whenever I need to initialize X, I just reference _x directly (usually in one place) but this is messy. It would be much cleaner if the following syntax was available:

    public type X

    {

    type _x;

    get { return _x; }

    protected set { _x = value; }

    }

    then I could still assign to the property inside the class while keeping it read only to external code.

    One possible additional feature of the above syntax that would further protect the field storage is to make any fields defined within the property unavailable to code even within the same class. That way you would be sure that all access to the field is done through the getter and setter and never directly on the field.

  103. Orion: I see. I was thinking just the binary serializer. I agree with you on the XML Serializer. Writing should only need your getters. Readers should only need your setters.

  104. JimG: Protected setters are available in C# 2005.

    Aleksei: Email it to me. Thanks!

  105. JimG says:

    Cyrus: Great to hear about protected setters in C# 2005. Is storage of fields in property syntax and the hiding of fields from anything other than the getter and setter of the property coming as well? One can hope <g>

  106. To all of those you talking about properties:

    We considered heavily adding a default backing store for properties. We considered some different syntaxes like:

    public int Foo {

    get { return value.private; }

    set { if (validate) { value.private = value; } }

    }

    and other oddities :-)

    However, it was decided that this really didn’t provide a large benefit to users except to cut out a small amount of typeing. Whereas something a property with different accessibility in the get/set was something you couldn’t do period in C# (and so we added it to 2005).

    Instead we decided on improving the editor experience so that this wouldn’t be such a pain on developers to type. We added to things to help you. "Expansions" and "Encapsulate field".

    You can now type:

    "prop<tab>" and all you have to do is type the return type and the name of the field and prop and everything will be spit out for you.

    Or you can type your field and hit: ctrl-r-f to encapsulate the field into a property (and we’ll automatically decide on the name for you).

    Does that info help?

  107. Darren: where’s the list of features :-)

  108. darren: I’ll pass on your feedback to the VB team (and i’ll see if they havea blog so you can talk to them yourself).

  109. JimG says:

    Cyrus: Saving typing is not really my concern here, sorry I haven’t been more clear. I’ve always thought of properties as mini-classes. They have methods (a getter and a setter) and data storage (the field). Like a class, a property should be able to define it’s data storage so that it would be hidden from all other code, except it’s getter and setter, including hiding it from code within the same class.

    Otherwise, with the field syntax separate from the property syntax (thus making it harder to see the direct relationship between the two), it is much easier for a developer not entirely familiar with the class to read or write directly on the field and bypasses any code that might be in the getter or setter (leading to some rather nasty and hard to find bugs).

    Basically, a private field is not private enough if the only thing that should access the field is the getter and setter of the property. Of course the current syntax of a field outside of the property would still be available if direct field access was required but then the developer is accepting the risk.

  110. JimG says:

    Cyrus: When I said that saving typing is not really my concern, I meant for this particular feature request. Of course I’m drooling at all of the new features coming out that will save me gobs and gobs of keystrokes. Keep those features coming! <g>

  111. Ron Buckton says:

    Cyrus, I’m just grasping at straws here but doesnt a Thread in .net 2.0 track ExecutionContext, such that a second thread can call back into the main thread? I havent had an opportunity to peruse the documentation on System.Threading.Thread, or System.Threading.ExecutionContext (or SynchronizationContext, etc.) to see how all of this works. But as far as I can tell you should be able to synchronize an async thread with the calling thread using these contexts. I would imagine an "async/sync" set of keywords to provide compiler expansion similar to how i’ve heard "yield" works on iterators.

    From a WinForms point of view it is a pain to write multi-threaded apps that update the UI, and you have to go through a lot of workarounds to make this happen. IMHO C# could stand some better features to make multi-threaded development easier. To me:

    public class MyForm : Form

    {



    private async void SubmitBatch(DataSet batch)

    {

    … some long running process …

    sync

    {

    this.Text = "50% complete.";

    }

    … more work …

    sync

    {

    this.Text = "Done";

    }

    }

    private void submitButton_Click(object sender, EventArgs e)

    {

    … compose dataset…

    this.BeginSubmitBatch( ds, delegate { MessageBox.Show("Completed!"); }, null );

    }

    }

    I think it’s a bit cleaner than either writing your own IAsyncResult and having to deal with your own threading. the System.ComponentModel.BackgroundWorker seems to give you the kind of functionality you might need but it seems so over bloated for this kind of need. It also doesnt give you the true Async methods that are used throughout the framework. If i can create a delegate that automatically has an "Invoke", "BeginInvoke" and "EndInvoke", why can’t i do the same for a method on a class or struct?

  112. JimG: Interesting take on the property. But if that is the case, you might want to actually consider using a class to accomplish that goal. If encapsulation of state is important, then it would accomplish that the best way.

    something like:

    IProperty<T> {

    T Value { get; set; }

    }

    IProperty<int> ageProperty;

    int Age {

    get { return ageProperty.Value; }

    set { ageProperty.Value = value; }

    }

    then if anyone every actually tries to use age (like "ageProperty = 5") then they will have a problem.

    I’m not disagreeing on this though. We will look at this and consider it carefully given the amount of requests we’ve had

  113. Ron: In C# you can pass a method to something that expects a delegate and we’ll automatically create the new delegate for you. Would that work?

    i.e. instead of having to do:

    new Thread(new ThreadStart(someMethod)) you can do:

    new Thread(someMethod)

  114. Ron Buckton says:

    Cyrus, I am aware of that (and even use the concept of an anonymous delegate in my hypothetical example).

    My statement is in regards to the fact that the .NET framework consistently uses BeginMethod/EndMethod/Method for asynchronous invocation on delegates, controls, web-services, etc. However these functions are time consuming to write. In addition thread synchronization to report progress is a nightmare, mitigated only slightly by the forthcoming BackgroundWorker class in System.ComponentModel.

    using something like a method attribute like "async" would inform the compiler (and also intellisense) to autogenerate the Begin/End methods similar to how "yield" in an iterator generates a private class to manage the state of the iterator. This is already available through the use of a delegate, as I can call BeginInvoke on a delegate but this means that the Begin and End methods are not first-class members of my class. In addition i still have to resort to "hack"-like workarounds for thread synchronization (Control.BeginInvoke…) to post progress back to the UI thread.

    the "sync" keyword would perform synchronization, block the async thread temporarily and inject a call into the calling thread to provide progress. you could also use "async" as a block statement as well to possible post progress w/o blocking, e.g.

    privat async void SubmitBatch(DataSet ds)

    {

    // .. do long process …

    async

    {

    // .. this block is passed to the calling thread and executes immediately w/o blocking the async thread

    }

    // .. do more long process …

    object someResult = null;

    sync

    {

    someResult = SomeMethodCalledFromCallingThread();

    }

    }

    the async and sync statement blocks in this example might take in an optional ExecutionContext to call to, in the case where you have a more complex threading application.. e.g.

    Thread firstThread;

    private async void SubmitBatch(DataSet ds)

    {

    sync(firstThread.Context)

    {

    }

    }

    although I do not have a proposal for acquiring specific details about all of the running threads… just my 0.02

  115. Ron: I gotcha now :-)

    Very interesting idea. It syncs (no pun intended) with the kind of code hiding that anonymous delgates/iterators does for you.

    really interesting idea!!

  116. Aleksei Guzev says:

    Will the ‘async’ block in the example have acces to local variables of SubmitBatch method? What objects actually can live in this block an dwhat objects are visible from this block? Could the same co-routine behaviour be achieved with anonymous delagtes passed to SubmitBatch as parameters?

  117. Kevin Downs says:

    XML Comments

    —————–

    1. The smart-tag for renaming a parameter should also modify any corresponding <param name="parameter_name"> tag.

    2. The auto-generation of xml comments by typing /// above the type/member should use the templates functionality so it can be customised.

    3. A cref syntax that points to all overloads of a method – something like <see cref="SomeMethod(*)"/>

    At present, the compiler always resolves to a specific overload, which makes it impossible to link to an ‘overloads’ page.

    The current xml comments spec states that methods without parameters should not have parenthesis in the generated xml. If this were reversed, then documentation generators could resolve to the specific, no parameter, method when the parentheses are present, or to an overloads page if no parenthesis exist.

    4. A quick way to collapse all code comments. This would make code navigation a lot easier.

    5. Some way to add a custom xsd or other mechanism to make the xml comments intellisense aware of user-defined tags.

  118. I have posted an example on class for classes

  119. Aleksei: Are you talking about System.Type? If so, I’m not sure what you’re actually asking for…

    I’m really sorry. Can you provide an example (email me if you want) that shows what you would like to be able to do and what you are unable to do to now.

  120. I cant find Your e-mail. Please take a look at

    http://metaclass-guzev.blogspot.com/

  121. Robert Jeppesen says:

    About the VB/C# difference in features. One must also remember that language choice is not always up to the developer. Employers are hiring .Net developers, not C# or VB developers, and then lang choice becomes a ‘strategic’ decision. The two langs should be equally powerful. Make them use one compiler, as stated above!

  122. Every language has its goal. Employers should choose laguage according to the task, but not to their preference.

  123. Aleksei:

    I agree with you wholeheartedly. But since when has anyone been able to tell management anything? In my case, my company (a very large one, in australia) is choosing C# for (what i can work out) one reason, and one reason only. They used to be a Java house. They still want to be, but MS has been winning it’s way back in :) C# is ‘approved’ because it looks a lot like Java. End of story.

    They’re all a bunch of wankers.

    Having said that, i’ll refrain from mentioning my who my employer is :)

  124. David Levine says:

    Cyrus,

    Exception filtering: this is powerful because you can execute code before the catch handler is selected and the stack has not yet been unwound. This currently may be of interest primarily for tool vendors – one could do a dump of all local variables before the stack gets unwound and the variables go out of scope. Also, if a true resumable/restartable exception mechanism is ever implemented this feature will be useful e.g. for popping up a dialog for true Abort/Retry/Ignore semantics.

    VB exposes a limited version of user-filtered exceptions that allows for simple testing to determine if a catch handler is executed. Exposing it so that arbitrary code can be executed would allow us to put up custom dialogs asking how to handle it, perhaps for data entry, etc., and if the decision is not to handle it the exception would continue up the callstack unmodified.

    Related to this, it would be useful to add a method to the BCL called CloneException so that the original exception type can be propagated up the callstack and still be able to add context information to the original exception. I’ve written this routine for my own use (it’s rather trivial) and others may find it useful as well. It’s signature is

    System.Excepion CloneException(Exception innerException,string msg);

    and use it as:

    catch(Exception ex)

    {

    // 1st try to handle it here…

    throw CloneException(ex,"I fell down and can’t get up.");

    }

    And why not add support for fault blocks?

    MSI Generation:

    One limitation is that currently there is no abilty to edit the builtin dialogs, so if there’s a need to make a change (e.g. disable some radio buttons), you have to jump through hoops to do it and still have an automated build. I currently create a MSI transform and run it on the msi files after the build has completed.

    It would be useful to have an ORCA-like view of the MSI tables. I’m not a setup expert so I know there are lots of other features I haven’t thought of. In general we need better integration of setup file generation into the IDE.

    One feature would be huge….add a MSI debugger so that you could run the MSI file as if it were running during an actual install, but still be able to step through managed custom action code, set breakpoints, etc. Currently testing custom actions written in managed code is a HUGE PITA. It’s even worse when trying to test complicated scenarios, such as upgrades, rollbacks, etc.

  125. Cleve Littlefield says:

    Cyrus, by macros I just mean VS macros. Drop VBScript or any other script for that matter. I will be happy if I never have to use a scripting language again.

    I think you thought I meant some sort of macro like the old c preprocessor macros. No I dont want those. But I think someone mentioned attributes for interfacing with the compiler. That would be awesome, instead of just adding some metadata. I know the compiler treats some attributes special and generates special code, if you let us do the same (maybe a special base attribute CompilerAddinAttribute or something) that has methods to add some IL to the current attribute target, that would be incredibly powerful.

    The guy that mentioned all the xml comments is brilliant. If you rename a param, the xmlcomment should be changed automatically.

    On the VB == C# thing, I see what you mean that maybe the primary users of one language will not want some of the features. So maybe you need to do a better job of figuring out which features they DO want. So maybe VB guys dont want anonymous delegates, but when you add 2 huge features like Edit and Continue and the My classes, us C# guys groan because we want them too. Now we have to wait for another release cycle to get them. This might be as simple as shorten your release cycles, since then if you do give one camp a feature and you get grief from the other camp, they dont have to wait too long for you to make it up to them.

  126. Kevin: Rename will fix up xml doc comments

    Other suggestions added to the main list.

  127. Cleve: Part of the reason I have this blog is so that we can figure out what features C# users do want. Hence the blog title "What features would you like in the next version of Visual C#"

    It’s feedback like this that tells us where we should be moving and tells VB where they should be moving.

    For example, see the post from "Darren Oakey" who wants VB to move in a different direction altogether. How do we balance those goals with C# goals.

    We are absolutely listening to what you want. But we’re also listening to the people that ask for conflicting things. We’re trying very hard to figure out what the best choice is in those cases. And, while I can’t speak for anyone else, I’m committed to getting your feedback when those issues arise so we can ge ta feel for whether it’s right or not.

  128. damien morton says:

    I read a lot of people asking for help defining properties and their backing stores.

    The examples, without fail, look something like this:

    int _x;

    int X { get { return this._x; } set { this._x = value; } }

    I keep asking myself, what value there is in having a property declared like that. It serves no function whatsoever.

    Actually, I take that back. It serves one function – a PropertyGrid wont display fields.

    The only other use I can think of is for providing read-only-ness or write-only-ness.

    int _x = 45;

    int X { get { return this._x; } }

    The other usefull traits of a property are that it can be declared virtual, where fields cannot, and that a property getter/setter can perform more work than than simple assignment.

    Have I missed anything?

  129. Damien: There is a purpose in that. By encapsulating your state you are making sure that in the future you can change the behavior without anyone breaking you.

    If you use a read/write field and then change to a property in the future then all code compiled against your old code will fail.

    Note: you may also be implementing a property because it was declared in an interface. In that case you might just want it to be one of htese simple properties that people have mentioned.

  130. I have started my own blog to not flood this thread with my ideas being sometimes impractical :(

    http://language-guzev.blogspot.com/

  131. using <class> is like with <an object> in Pascal. And I think there is a situation where such a feature will be useful.

    The foreach statement always involves declaration of a local variable:

    foreach( XmlElement element

    in doc.SelectNodes(xpath) )

    {

    Console.WriteLine( "{0} of type {1}",

    element.Name,

    element.GetAttribute("Type"));

    }

    How often You name the variable with i? While there is always the special variable in the foreach statement it’s possible simply omit its name:

    foreach( XmlElement in doc.SelectNodes(xpath) )

    {

    Console.WriteLine( "{0} of type {1}",

    Name, GetAttribute("Type") );

    }

  132. using <class> is like with <an object> in Pascal. And I think there is a situation where such a feature will be useful.

    The foreach statement always involves declaration of a local variable:

    foreach( XmlElement element

    in doc.SelectNodes(xpath) )

    {

    Console.WriteLine( "{0} of type {1}",

    element.Name,

    element.GetAttribute("Type"));

    }

    How often You name the variable with i? While there is always the special variable in the foreach statement it’s possible simply omit its name:

    foreach( XmlElement in doc.SelectNodes(xpath) )

    {

    Console.WriteLine( "{0} of type {1}",

    Name, GetAttribute("Type") );

    }

  133. Darren Oakey says:

    "MY C#"

    A <grin> quick list of additions/ changes I’d love to make to (the already great) C#.

    ==1== things in regions in a different color ====

    Saw this suggestion in the list – while I hadn’t thought of it myself, I love it – I would like to be able to assign a different background for something inside a region – and have them toggle – ie

    blah ; default background

    #region something

    blah ; "region" background

    #region internal

    blah ; default background

    ==2== expose syntax colouring engine ====

    I would love some way of adding my own coloring things – for instance, anything starting with the word Test in a different color :)

    ==3== allowing limiting to explicit or implicit interfaces ====

    Some people think explicit interfaces are a good idea… some people think implicit interfaces are a good idea. Very few people, I think, would think they are _both_ a good idea. It would be really nice in the compiler to have an option (allowed interface implementation = implicit|explicit|either) – because I would dearly love a compiler error in the case of an accidental implicit interface definition – it has often happened that I’ve created a function of the same name, and haven’t noticed I haven’t explicitly implemented the interface – and while it always has the obvious result – it’s NOT something I’d really like hanging around in my code!

    ==4== intellisense shows base constructors when typing ====

    Everyone has put in their 2c about constructors and inheritance, so I’ll stay away from that one, but it would be very nice if there was some easy way to create the constructors. I’d like it if the intellisense list included a definition of every base constructor in it – ie if you have class

    class B {B( int x) {} }

    class Blah : B

    {

    when you type

    Bla

    the intellisense list has in it:

    Blah()

    Blah( int x ) : base(x)

    so you just have to hit down and tab to implement the bottom one

    ==5== "expose" keyword ====

    basically just a code generator – you could use it on objects, methods or properties… eg:

    public class A

    public void Go();

    public int Calculate( int x );

    then we write

    public class B

    private A _theValue;

    private String _secondValue;

    expose _theValue;

    expose _secondValue.Length;

    is exactly the same as writing

    public class B

    private void A _theValue;

    public void Go() {_theValue.Go();}

    public int Calculate( int x) {return _theValue(x);}

    public static implicit operator A

    public int Length {get {return _secondValue.Length;}}

    I’ve made a macro that does it, but that generates the code – I want the code to dynamically update as I change A, and I think the "expose" syntax would be a very clean and obvious way of doing it

    ==6== information about code, where we are coming from ====

    I’ve asked for this b4, and had lots of discussions about it, but I’ll say it again… first, the obvious : __line__, __file__, __class__, __method__ variables,

    then the C++ macro object #symbol yields "symbol"

    and finally, the more exotic "ParamInfo" reserved word, such that

    public void Blah( string k)

    {

    ParamInfo kParam = ParameterInfo( k);

    }

    the compiler actually builds a function internally called

    public void Blah( string k, ParameterInfo k kParam)

    and any time you call it, the compiler throws in extended information about the call

    so if you do

    string a = "blue";

    Blah( a );

    ….

    then kParam.IsLiteral => "false";

    kParam.Value => "blue";

    kParam.Name => "a";

    kParam.ObjectDataType => string;

    only occasionally useful, but VERY easy to implement, and the few times you do use it tend to be pervasive through the application (debugging code, logging code, tracing code, error code, assertions etc) so there is a HUGE potential benefit

    ==7== stack trace with parameters =====

    Back in VB, I wrote my own exception mechanism and stack tracking object. It involved you doing the following:

    sub AnySub( int x, int y)

    begin

    on error goto errorHandler

    exit sub

    errorHandler:

    HandleErrorIn "AnySub", x, y

    end

    While it was annoying to add to every function… We did, and it was invaluable. Any error happened in production, we got a complete call stack emailed to us, and because no work was done except in the error handler, it was very efficient.

    However, probably the MOST useful thing in it, and what .NET is sorely lacking (even to the point where in some critical apps, I’m adding my own exception handler to every class again)… is this: I NEED the values of the parameters!!! It doesn’t really help to know that saving the employee failed – I have unit tests assuring me that employees always save correctly! I want to know _which_ employee they were looking at at the time!

    What I don’t understand is – the stack trace in debug mode does this beautifully – where does it all go once you are in production? It’s not like you need to optimize that code out – there is zero performance impact unless an exception occurs, so who cares? Sure, there’s a possible security implication – but if you care, (and most people won’t) you can just put your own custom exception handler on. PLEASE give us this info!

    ==8== get rid of regions for implements ====

    Well actually, my biggest problem with regions and interfaces is that you tend to end up with four of them… but if I had the option, I’d turn generating a region off entirely. Can I have that option? :)

    ==9== interface into the code parser ====

    When it comes down to it, even though you have the obvious danger of having all sorts of bizarre variants of C# around – I think the benefits are worth it, because with this, I could do almost every request on this list (including aspects) .. – a sort of way of defining your own reserved word, say for example "nonnull", and calling a custom function in a dll when that is encountered – that function would do some sort of modification to the code.

    So – it wouldn’t be so much a way of interacting with the compilation process, but a more intelligent version of C++’s macro’s language – a preprocessor. In a pre-compilation step, the system would scan for reserved words/patterns, and call functions to modify the code into what it should be. That code would then be compiled. Because it works on the code dom and stuff, it can at the same time be far more powerful than C++ macros, but also be more robust.

    ==A== inherit from templated class ====

    We really want the ability to say

    class AddCalculateTotalTo<T> : T where T:ICalculatable

    basically, the ability to inherit from a templated class gets us a tiny way further towards AOP, because we basically have an "add functionality to class" methodology".

    ==B== const

    ok.. we need const. I’ve seen all the arguments against it – people who say we don’t need it I dismiss as not being very experienced programmers – people who say it’s too difficult to add to the library – I understand… but I’ll give an example alternative to actually literally having it :

    I’ve been thinking – you could actually implement const quite smoothly with a preprocessor… If you have

    public void Blah( const string x )

    then you immediately look up your table and see if you’ve already generated "IConstString" – if not, you generate IConstString, which surprisingly enuff is an interface to all the non-changing functions on string (ok – you might need a bit of logic to work that out, but it’s not impossible) – You also generate IConstWrapper, with an implicit cast from const, and bang… your code is suddenly

    public void Blah( IConstString x) – and it all just upholds constness perfectly… _without_ any necessity of the runtime library to understand const…

    ==C== fix up "using" definitions ====

    I use a cool prog called C# refactory, which we wisely convinced our work to purchase for us. The only function I use a lot on it, but completely justifies its purchase, is "Tidy imports". This goes through the whole class, and throws away any using directives which aren’t actually required, ordering the rest of them in a logical and alphabetical order.

    ==D== Convert to "using" ====

    I hate (in fact our code standards (which I wrote :)) say you are not allowed) – having fully qualified names… how readable is x = system.math.min(5, 3) – I insist on x = min(5,3) (well, actually, I say x = Math.Min( 5, 3), but I’ve already begged to be able to do the VB-Like using of a class, and I won’t reiterate..

    What I would love, is to be able to right click on "System.Math.Min" and say "Convert To using" and have system.math split out of everywhere it’s being used, and the line "using system.math;" added to the top of the screen.

    ==E== add references just by typing using ====

    To go a little further – how redundant is it to type using system.windows.forms, and then go up to the project, and click "add references". Programmers want as little context switching as possible – ideally you are looking at a block of code, and doing most of the stuff with that block of code – this is where things like "go to definition" are so amazingly brilliant. If it’s in the list of registered assemblies, or a project in the current solution, it wouldn’t take much smarts at all for the intellisense engine to go – "oh, and you’ll be needing this, sir"…

    ==10== tuples

    Ok – this is fixed somewhat by generics. I finally have my Pair<firstResult,secondResult> class, but it would be nicer just to be able to return (string, int)

    ==11== "delegate" equivalents for properties

    This is obvious – but the two hacky ways of passing a "reference" to a property at the moment are pretty unacceptable… I don’t want to create get and set functions, and I definitely don’t want to be addressing the property by it’s string name equivalent!

    ==12== method scoped variables

    ok, I don’t care who you are, you should agree that

    class x

    {

    private _counter = 0;

    public int NextValue {get {return _counter++;}}



    }

    is almost identical, but always inferior to

    class x

    {

    public int NextValue

    {

    get

    {

    static int counter = 0;

    return counter++;

    }

    }

    }

    purely because you don’t know what’s under the "…"!!

    == 13 == thread synchronisation stuff =====

    this basically comes down to having thread flags, and "wait for flag" type functions

    == 14 == documentation assistance =====

    I think there’s a lot of room to extend and enforce code documentation – for example, allowing you to point at an existing function as an example of the use of another function… But the main thing is, the automatic integration of xml documentation into your local msdn code library, without the user changing anything – I don’t think enough people are using xml documentation, and if you did an "in your face" – click F1 on any of your own functions and you get help on that function, people would actually bother using all those other (seealso, remarks etc) functionality

    == 15 == Functions in module scope =====

    OK, I am going to mention it. Math.Min is really just NOT GOOD ENOUGH. When it comes down to it, to me, the measure of the quality of code is simply this :

    "how long would it take someone who doesn’t know anything about programming to understand what it’s doing"

    and when it comes down to it…

    the line

    x = Max( 5, Min( 10, value));

    is fundamentally more readable (therefore more understandable, therefore more maintainable) than

    x = Math.Max( 5, Math.Min( 10, value));

    Remember, we can right click and say "go to definition" if we want to know where it’s defined – so we don’t need to think about this right now – we are trying to understand the BetweenValue function!

    ==16== literate programming =====

    Now I’m just going silly, and playing with it – but I used to LOVE Miranda because it had a literate programming mode… wouldn’t it be cool to have the same thing in C#? I actually, for a language like C#, wouldn’t use it all the time, but would probably just have it in my high level "interface description" classes, but it would be nice..

    imagine

    ———— cut here ————

    <literateC#>

    Comparable

    This interface specifies that two objects are comparable. blah blah blah

    blah blah

    blah blah

    example

    blah blah

    > public class IComparable

    > {

    blah blah

    blah blah

    blah blah

    blah blah

    blah blah

    > int Compare( object x, object y);

    > }

    >

    ———————————-

    I know most people wouldn’t want it, but it’s also one of those things that’s almost trivial to implement.

    ==17== directly declare new object without doubling up =====

    Who out there gets upset with

    Blah x = new Blah( 10, 2 );

    VB has this beautiful

    dim x as new Blah( 10, 2 );

    while can’t we do

    Blah x( 10, 2);

    or at worst

    new Blah x( 10, 2 );

    While we often won’t be setting an object of type blah to a value of type blah – we often will, and the code to do so is so cumbersome.

    ==18== remove event declarations when the function is removed

    like everyone else, I double click on a form to get into it (right clicking and saying view code just seems slower). Like everyone else, I get a form load… like everyone else, I remove it… like everyone else, I hit compile, and wait for the compiler to tell me where the line is, and like everyone else… I then remove that.

    now – I LIKE the fact that I get an event handler when I double click on something – I find it useful. I also tend to take them out often as well..

    what would be the nice is when I delete the function, intellisense jumps in and goes "ahh.. so you won’t be needing THIS then, will you?" – although maybe it should prompt you when it’s doing it?

    ==19== stop controls being removed from the form ====

    ok – how many people are in terror of double clicking on a form? How many people have a form composed of four other user controls from the same project – we foolishly open the form when the project doesn’t compile and oh cool – our code is now completely and utterly corrupt! NOT JUST have the controls been REMOVED from the form, but the definitions of the controls HAVEN’T. So – we can’t easily recreate controls of the same name, even if we can remember every possible change we made to the control’s properties. we first have to laboriously go through and remove the definitions of those controls.

    Now – I don’t see a need for the IDE to remove the controls without telling us, just because it can’t instantiate them? I see a need for a black box with a red line through it, and the text "this control can’t be instantiated"!! I can’t think of a single reason you would _ever_ want this functionality? It’s not like you are responding to code changes.. even if people rename a control, or change details on it, they aren’t wanting the usages of it to just magically vanish!

    ==1A== returns from anonymous methods =====

    Ok, I’ve tried to use anonymous methods about 7 different times so far. On 6 of those occasions, I wanted to return a value from the anonymous method, and couldn’t figure out a way to do it? Why? To me, anonymous methods are a _very_ functional thing – lambda calc and all of that. If you are programming functionally, you ALWAYS want a return method. You want a function like FilterList, where you pass in functions like {return item < 10;}. Why can’t I return from an anonymous method? (or am I just missing something?

    ==1B== vi commands =====

    getting fruitloopy again – the editor is missing a vi-style command line key combination :)

    ==1C== inference of object array types =====

    ok, if I’ve got a function f( int [] values )

    why do I have do do f( new int[] {1, 2, 3} )

    why can’t I do f( {1, 2, 3} ) – as the compiler can by default infer the list to be the type requested by the function..

    ==1D== interface guarantee ====

    ok – I might be sick, but I MISS binary compability. I want a way (and maybe there is one, I don’t understand assembly versioning at all) of just saying "Here’s an interface, and this will always be my interface"… I write libraries which are used across the organisation, but also need to maintain and extend the library. I need a way of being able to do something like (maybe point to the production dll or something?) say "oh – and that’s what I need to be compatible to" – and get a compile error if I break something. Because, I need to be able to send out regularly a new dll, and say "Here’s the new employee class, everyone must use it" – but also know for sure that people aren’t going to come back to me and say "blah" doesn’t compile. Now – I’m pretty careful, so it rarely happens, but I’d like "rarely" to become "never".

    ==1E== delegate inheritance matching ====

    this is one of those stupid niggling things that is not really a big deal, but just gets more and more annoying over time.

    If I’ve got

    delegate object IndexingFunction( int x );

    and

    DoSomething( IndexingFunction y )

    and

    public string GetValue( int x ) {return "hello";)

    I want to be able to say

    DoSomething( GetValue );

    but I can’t because it says

    public string GetValue(int x) isn’t object f (int)

    well… I think it is :)

    ==1F== readonly method members ====

    I didn’t realise, Eric had to tell me about, the wonderful keyword readonly. So now, by default, I declare EVERY variable readonly, unless proved otherwise – yay!!

    so, I can do this:

    class x

    {

    readonly string _cachedTitle;

    x(Employee e) {_cachedTitle = ComputeTitleFor( e );}

    }

    What I can’t do (but I want to :)) is

    void blah( Point a, Point b)

    {

    readonly int width = b.X – a.X + 1;



    }

    ==20== pre-post condition specifiers ====

    this is one of those _not easy_ things, but it would be nice to be able to have pre and post conditions on methods, or variable declarations… initially just specifiers like boundary conditions etc (param<2) for example, but eventually ways of having things like class level flags which can be set in a template-like manner on classes. Some of these would have to compile into asserts, but some could be tested at runtime, for instance if you tried to send a literal negative number to something that took an int, with the precondition it was >0. I once read a fabulous book called "Generative Pogramming" that did this sort of thing with C++ templates, and it was quite powerful…

    but more than that, I’ve been thinking a lot about business objects and nulls. In most systems, business objects really don’t just "exist". They all have various states… they are partially entered while we are "creating the object", talking to the customer, getting their account set up, finance approval etc.. Then when we create their licence/account/lease/contract or whatever we do with them, we assume that certain values are present. Nullable doesn’t really cut it because it depends on the state you are in. Having a state doesn’t really cut it because you have lots of pseudo states, which all overlap.. What you need is some completeless requirement eg – "suitable for lease" which actually means [first name, last name, birtthdate, at least one contact value, at least one address, approved for finance]. Another requirement might be "Contactable" which just meant [a name, at least one contact value]… These "flags" you could define by using template parameters which are boolean, and define various implicit conversion operators to convert between them… so, by just including the concept of named, and boolean template parameters, you can end up with being able to have functions like

    CreateLease( Employee<SuitableForLease> value )

    or

    ShowContactDetails( Employe<Contactable> value )

    which gives you the ability to really start thinking in domain specific languages, and have the compiler lend a helping hand

    ==21== backing store for properties ====

    I’ve wanted this for a while, but I didn’t know the best way – I saw in your list a beautiful syntax, which I’d like to throw my vote in for :

    int x

    {

    int _blah;

    public get {return _blah;}

    private set {_blah = value;}

    }

    the only difference from this being

    int _blah;

    int x

    {

    public get {return _blah;}

    private set {_blah = value;}

    }

    that no one else can access _blah. insignificant? No – HUGE!!

    ==22== pinvoke.net ====

    OK – we’ve all been to pinvoke.Net and love it.

    BUT WHY?

    Why do we all have to invent the wheel?

    I’d love it included, but really, anyone out there could just build it and stick it out there on sourceforge for us… where is the assembly called WINAPI, which has ALL the WINAPI in it???

    ==23== aspects

    Another one for the "probably too hard" basket – but please, please – aspectJ has me eyeing the rival court.. AspectC# is a big want!

    ——————————————————

    Anyway, there’s a bunch of others which I already sent to Eric, and others that I haven’t bothered with because I can see that I might be one of few people who would want them.

    It’s not that I NEED the above features..

    I just think they’d just improve the strength (or in most cases, the robustness) of the language – I’m a big protectionist. I strongly believe in the stupidity of programmers (myself especially) – and want the compiler to do everything theoretically possible to guide people down particular common ways of doing things, prevent people doing cool "cowboy" stuff, and mostly prevent someone making a mistake!

  134. Darren: Your post was too long. There’s no way I’m going to read all of that. Jeez.

    J/k 😉

    Thanks for the feedback! I’ll respond soon.

  135. Darren: Ok. 1 at a time.

    ==2== expose syntax colouring engine ====

    I would love some way of adding my own coloring things – for instance, anything starting with the word Test in a different color :)

    Sounds like a great idea. If we can we’ll try to make it a plugin architecture so you can replace our implementation (or subclass it, etc.). Can’t gaurantee anything about if we’d support this or not though.

  136. Darren: ==3== allowing limiting to explicit or implicit interfaces ====

    Great idea. You could write an FxCop rule to do this though.

  137. Darren:

    ==4== intellisense shows base constructors when typing ====

    ==17== directly declare new object without doubling up =====

    I’m a big believer that the IDE should provide help in these areas. Similar to how += will prompt you to create a delgate.

    so as you type:

    "Blah"

    you’ll get a tip saying: "hit tab to insert "Blah blah = new Blah();"

    After hitting tab you’ll end up with the cursor between the ()

    Things like that.

  138. Darren:

    ==5== "expose" keyword ====

    I dont’ get it :-)

    More examples.

  139. Darren:

    ==6== information about code, where we are coming from ====

    ==7== stack trace with parameters =====

    ==9== interface into the code parser ====

    ==20== pre-post condition specifiers ====

    These are all part of a big category of giving you greator control over your code. We’re thinking about this a lot and how doing this the right way could get all of this for you for free

  140. Darren: ==8== get rid of regions for implements ====

    Good idea. Goes into giving the user control over the code we spit.

  141. Darren:

    ==10== tuples

    I want them :-)

    ==11== "delegate" equivalents for properties

    Yup. This kills me too.

    ==12== method scoped variables

    Hrmm.. Interesting idea. Looks like you’re trying to encapsulate a field so only this method can access it. Seems like you should have a class do that encapsulation instead.

  142. Darren: == 15 == Functions in module scope =====

    How do you solve the name resolution problems that arise? We’re trying to avoid all the issues you run into with C, even if there is a slight extra cost to it.

  143. Darren: ==19== stop controls being removed from the form ====

    The WinForms team has worked a _lot_ on this. It was one of their highest priorities. They worked with all teams to improve the robustness of the designer immensely and I hope it shows for you

    ==1A== returns from anonymous methods =====

    I need an example. I just do:

    delegate { return 4; }

    And that works :-)

  144. Darren: ==1B== vi commands =====

    Nah. Tons of devs here ask for vi and emacs modes as well :-)

    ==1C== inference of object array types =====

    I think that’s one of those low benefit changes. Plus there are issues with type inferencing. But we’ll look at it for sure

    ==1E== delegate inheritance matching ====

    Whidbey delegates support co/contravariance. So you’ll be all set.

  145. Darren: ==1F== readonly method members ====

    I’d like that too.

    ==21== backing store for properties ====

    We can that request so much that I think it’ll have to be looked at again. There are strong arguments for it, and not too many against it.

    Suggestions on preferred syntax are appreciated.

  146. Darren Oakey says:

    ==9== "expose" expanded ====

    Ok – the problem: I am always pushing the containment vs inheritance argument. Containment of other classes is good and necessary. Argument aside, there’s also normal reasons why you often need to "expose" functionality on underlying classes.

    For instance. Suppose I want a text box with a label beside it, so I can enforce company appearance standards. So, I make a control – LabelledTextBox – which surprisingly enough, has a textbox and a label in it.

    Then I have properties like this:

    public string Title {get{return _titleLabel.Text;}set{_titleLabel.Text=value;}}

    which is all well and good – but I ALSO end up with a long line of properties like

    public string Text {get{return _textBox.Text;} set {_textBox.Text=value;}

    and

    public string PasswordChar …

    that all do nothing else but pass through to the base object, making us look and feel like a textbox. It would be MUCH simpler if I could instead say

    expose _textBox.Text;

    expose _textBox.PasswordChar;

    which had exactly the same effect (behind the scenes generated code). Why don’t we generate the code? a) this is more readable b) it’s less breakable, but c) we ain’t finished yet…

    SOMETIMES

    we want to "expose" the whole object – in effect simulating inheritance. There’s a lot of reasons why, but I’ll give you one example

    one of the infrastructures I have to work with at the moment is very DB driven – there is one class per table, and the underlying "dbbase" class knows all about how to CRUD the object to a table. so VehiclePackage inherits from dbbase, Package inherits from dbbase.

    but.. of course, sometimes I actually put my oo hat on, and think inheritance can be useful – and as far as I’m concerned, VehiclePackage inherits from Package.

    So.. I have a problem.

    How do I solve it? Very cleanly. I create a third class, PackageTable. PackageTable is a vanilla DBbase object, with all the package fields in it. I then create a class called Package, which inherits from dbbase, but not for it’s own purposes, just for that base to be used for any if its ancestors. VehiclePackage then inherits from package, thereby inheriting from Package.

    I then "contain" PackageTable in Package, and override the Save method so whenever the dbbase object gets saved, the packagetable object gets saved etc

    So, very simply, without changing the legacy framework, I’ve got the one Save function saving to two different tables – yay!

    The only disadvantage is that all my fields are now off in PackageTable, which just exists in Package as _package.

    So, for every field Blah, I have to go and create in Package a field called blah, whose getters and setters correspond to the one in package.

    what I really want to do is just say

    expose _package

    – and have EVERY public property/method "exposed" or wrapped with a like named method (unless of course said name already exists, in which case we just don’t)

    The reason why I want it with the keyword expose, instead of just running a macro to insert the code as I have it at the moment is a) it’s cleaner, but much much more importantly b) if I add a property to PackageTable, I want it to turn up in Package, without having to revisit Package!

    (oh and did I mention it’s cleaner :))

  147. Wesner Moise says:

    You should check out my view of where IDEs are heading in the next three years, because I think that C# team may be in for a surprise and catching up, if they aren’t careful.

    http://wesnerm.blogs.com/net_undocumented/2004/06/whidbey_may_mis.html

  148. I have tried to explain formatting with CSS on

    http://language-guzev.blogspot.com/

  149. Wesner: I’m afraid we will not be able to eliminate the need to type in near future. Try using IBM Visual Age. While one can bind a listbox to an array by dragging, the main functionality is described in text. The machines we use are built to process streams of bits but not to interpret two- or three-dimensional graphics. I wish to have control over machine all the time. When I write a line I know what will machine do after it reached this line. Building a wall between machine and me is not a good idea. Graphical representation is useful, but it will not supersede text.

    In early XX they stated that cinema will supersede paper books. I’m sure we will use paper for some time more. And I prefer reading Tolstoy in text but not as comics.

    But the ability to visually bind properties on controls to properties of other obects would be nice! I like it.

  150. Aleksei: I blogged about formatting with CSS as well earlier.

    Check back through last month’s posts about ideas for the next formatting engine.

  151. Wesner: I’ve been coding for a long time and I’m an avid fan of the history of coding. This issue has been raised year after year after year and coding still remains equally (if not more) important in the process.

    If things change then we’ll roll with it and we’ll work hard to create great developer tools that target those changes.

  152. Darren Oakey says:

    ==24== event stores START initialized ====

    anyone recognize this code?

    if (EventX!=null)

    EventX( this, firstParam, secondParam);

    Of course, every now and then we all forget the if – and eventually get a null reference exception.

    Now – when you say EventX += myHandler – you don’t first do EventX = new EventX, do you?

    Any chance of either

    a) automatically initializing an event, when you define event x;

    b) behind the scenes inserting the above if statement when you try to cause an event?

    The only code I can imagine which could be broken by (a) is code that does something different if no-one is listening on the event [and anyone who did that deserves pain] and no code at all could be broken by (b) – in fact lots of existing code would be unbroken…

    Please! can we ditch the null test?

    ==25== event delegates ====

    I don’t know about you, but I would NEVER let anyone re-use a delegate definition for an event. reasons:

    a) you end up with people dodging strong typing, and casting their eventargs/sender values to what they were expecting, because they were too lazy to create their own delegate (although it would be nice to see a Generic control, which sent an event Click(T sender, EventArgs…) :)

    b) you get much less compiler support to change everything when you suddenly decide you want to send one more value to the event handler…

    c) you’re royally rooted if you’ve created three events that currently look the same, so someone has pumped them all to the same handler – then you go and decide one of them needs extra information.

    so, at the moment, I will always have the following code:

    public delegate void LockedHandler( LockButton source );

    public delegate void UnlockedHandler( LockButton source );

    public class LockButton

    {

    event LockedHandler EventLocked;

    event UnlockedHandler EventUnlocked;

    }

    (I hate it, but I prefix every event with the word "Event" so that we don’t forget to put the "if" in if anyone calls the thing)

    it would be really nice if we had the option (which would have _exactly_ the same effect) of doing this:

    public class LockButton

    {

    event void EventLocked( LockButton source );

    event void EventUnlocked( LockButton source );

    }

    which basically creates delegates called LockButton.EventLocked, LockButton.EventUnlocked, and declares two events with the respective delegates…

    the syntax is FAR more intuitive, the implementation safer, and it encourages people strong typing their delegates, instead of sending the "object sender" – I mean I understand why such a horrible compromise was necessary, but we have generics now – we don’t need to ever use object again! [kidding]

  153. JD says:

    Cyrus,

    A summary of this would be great.

  154. JD: I will post a summary next week. I’m still getting feedback. It’s going to take a while to get it al together :-)

  155. Pargunan says:

    Create an Add-In features will be great………….

  156. Milen says:

    Your blog is very interesint