C# 4.0

[PIEBALDconsult]

Yes, we agree on that.

[Jon Rista]

aaa) I prefer having them in their own namespace. That forces you to think about using them. To support your argument, it forces you to do something that will cause a "ported" app break at compile time if that extensions namespace isn't available. It also allows you to interchange extensions that do the same thing. If you decide you can do better than Microsoft and write the same IEnumerable extensions, that produce the same results, but perform faster...since they are in a different namespace, you can! Extension Method Best Practices[^] In regards to inheriting to extend functionality. Inheritance is good only to a certain degree, and is not always the appropriate answer. For one, there is the ongoing Composition vs. Inheritance debate. Two, deep inheritance chains are difficult to maintain and manage. Three, your not always looking create a whole new type. You just need more functionality on an existing type. The beauty of extension methods is, if you DO inherit from an extended type, your extensions are available on all derived types too. The only real caveat with extension methods is the possible future inclusion of a similar method name on the extended class. I havn't figured that one out yet, but I doubt I'll completely give up on extension methods because of one possible problem. Having extension methods replaced with a native method isn't necessarily a bad thing, either. For example, I have an extention method that determines if an ObjectContext for Entity Framework "contains" an entity. The result is either true or false...and the rules that determine that are static. I don't care if the implementation comes from my extension or a native implementation...I just need to know the result.

[Sunny Ahuwanya]

Jon Rista wrote:

Extension Method Best Practices[^]

Thanks for that link.

Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry

[S Senthil Kumar]

Vikram A Punathambekar wrote:

Only if the excception is not handled.

True, but isn't that the typical case? I generally find that the exception handling part is usually several layers above the throwing part.

Vikram A Punathambekar wrote:

I am a big fan of Java's checked exceptions.

Is it because of the documentary value (listing of all possible exceptions that could be thrown by a method)?

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

[Vikram A Punathambekar]

S. Senthil Kumar wrote:

Is it because of the documentary value

Partly. I like better the fact that it forces developers to handle exceptions, or at least advertise them so the calling code will. It also means your app will almost certainly never crash due to a checked exception being thrown. But the best of intentions of the language designer can be undone by wilful wrongdoing by the developer: I have seen far too many methods where all the code is inside a try block, followed by an empty catch all block :wtf: ; or a method that throws a few specific checked exceptions but has the signature void functionName(int someParam) throws Exception. :((

Cheers, Vıkram.

---

"You idiot British surprise me that your generators which grew up after Mid 50s had no brain at all." - Adnan Siddiqi.

[Yortw]

Sorry, that is true... except some of them are IDE features and not .NET ones :)

[Yortw]

Last time I checked the bug report on connect.microsoft.com they had marked it as closed, "Won't Fix"... and I thought that was after 3.5 was released, but I could be wrong.

[Yortw]

Sorry, you are correct, they fixed it in 'orcas'.

[Scott Dorman]

Actually, I think the whole problem would be better solved by lifting the . operator in the same way they did for some of the other operators to handle nullable types. It is essentially making nullability a true first-class language citizen, whereby accessing a property or calling a function on a null object simply returns null rather than a NullReferenceException.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

Tuple support is certainly nice but there are other ways to handle this. Simply having some predefined Tuple<T> type classes like we have with Func<T> and Action<T> would be more than sufficient, I think.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

Optional parameters will probably be there. Const paramters are doubtful although it would be nice, at least as a compile-time check.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

Giampaolo Papotti wrote:

And what about the annoying lack of default in parameters? I'd like to see c# designers and gurus dealing with Office PIA... I'm sure they would have a private build of csc.exe with default parameters implementeed .... InvokeExcelStuff(theOnlyNeededParameter, null, null, null, null, null, null, null, null, null, null, null, null, null, null....)

This should become simpler...stay tuned.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

Extension methods are just like any other language feature...they have the ability to be misused/abused (and not just from newbies, but by anyone). I don't think that's a good reason to not include a feature or we would end up writing assembly again. How do extension methods force you to write bad code? If you don't want to use them, don't use them. It's that simple. Yes, there should be more guidance on how to properly use/write extension methods (which is coming) and possibly some better compiler support to enforce that. I disagree with the ability to add extension methods in the same namespace as one that's defined by Microsoft. This isn't actually polluting a namespace but rather polluting a type, but that's kind of the idea behind extension methods. BTW, other languages have similar features as well and are usually called Mix-Ins. The thing to remember about extension methods is that they are nothing more than an alternate syntax for calling a static method on a static class. They are defined in exactly the same way (with the addition of the "this" keyword in the parameter list) and compile to the exact same IL as if you were to call it the "normal" way (i.e., as a static method on a static class and pass in the object you want to modify/act on). Calling it as an extension is a more natural syntax, but it's all syntax sugar/compiler magic. Extension methods do not have access to the internal state or variables of the class they are extending. You also can't use an extension method with the same signature as a native method...you can declare one but there is no way to actually override the native method with your extension and it won't show up as an available method in intellisense so there is no way to call it except as a static method on a static class, in which case you no longer have the extension syntax and it's completely clear which method is being called.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

That would be very nice to have.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Scott Dorman]

Member 3976638 wrote:

A couple of things I would like is better control over memory. The automatic garbage collection is nice and I understand that it's usualy better just to let it be so it can collect when needed, but in some cases I know the memory can and must be freed like when processing a large import file. Also I would like to be able to "Destroy" an object in certain situations. By that I mean to have one method that can nullify all refrences to a particualar object.

In .NET, nulling an object does not release/free any memory used by that object. In your example of processing a large import file, a lot of how you interact with the file will determine the memory used, but if you're using streams at all you should be disposing of those streams when you are finished with them. Also, keep in mind that if you load the entire file into memory at once and the resulting object is over 85K in size it's ending up on the large object heap which has different rules with respect to how the GC runs. If you absolutely need to reclaim the memory, you can call GC.Collect(int generation, GCCollectionMode mode) overload and use a GCCollectionMode.Optimized, which will only run the collection if the GC determines it is needed or GCCollectionMode.Forced, which will force a collection. If you do things like this, you need to be very careful about it as every time you run a collection cycle your application's main thread (and any threads it creates) will be frozen during the cycle.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[mvonballmo]

There is an extension of C# available that provides some help in this area: spec#. I haven't used it myself, but I'm a big fan of Eiffel, which has deep design-by-contract support. Spec# includes notation to indicate that a variable or parameter can never be null. BTW, if you're really interested in further reading on features for C#, the Eiffel language is a good place to start, as a language that has true generics since inception as well as tuples, anchored types, parameter covariance and many other interesting goodies.

[Roy Peled]

Hi, I wrote down my wish list for future versions of C# in my blog: My Complete C# 4.0 Wishlist[^] I'd love to get your feedback on any of these suggestions.

[Roy Peled]

Hi, Regarding the idea of tuples, I'll have to strongly disagree with you on that one. I wrote all about it here: Tuples are Evil[^] !! Specifically for your example, I fail to understand why you think your suggestion:

public int,int MinMax(int[] numbers)
{
int min, max;
// Code to calculate min/max
min=whatever
max=whatever
return min, max;
}

is better than the existing:

public MinMax(int[] numbers, out int min, out int max)
{
// Code to calculate min/max
min=whatever
max=whatever
}

The version with out parameters is shorter to write (!), you don't need to declare min and max in your method and you do not need to return them, just assign max=whatever and min=whatever like you have to do in the tuple version anyway. It's also safer since the compiler will make sure you assign something to each out parameter. and more importantly- the version with out parameters is more informative to the user! Let's check out the usage of each version: tuples version:

int min, max;
[min,max] = MinMax(new [] {1,2,3});

out parameters version:

int min, max;
MinMax(new [] {1,2,3}, out min, out max);

The usage is pretty much equivalent, except that in the out parameters version you will get helpful auto completion about the parameter names, so it's easier to write! The only thing that keeps the out parameters version from being perfect is the lack of support for optional parameters, which is #1 on my wish list for C# 4.0.

[Chris_McGrath]

I'd like to see them fix automatic properties. A lot of people have complained that there should be a way to set the default like... public int A { get; set; default { return 1; } But i think they should take it further. I'm a big fan of the CSLA framework hence i have a lot of properties following

    public int A
    {
        get
        {
            CanReadProperty(PropertyNames.A, true);
            return m\_a;
        }
        set
        {
            CanWriteProperty(PropertyNames.A, true);
            if (!m\_a.Equals(value))
            {
                m\_a = value;
                PropertyHasChanged(PropertyNames.A);
            }
        }
    }

(I know new CSLA is different but it's still just as much repetition) I would love to be able to say

public int A { get; set; from CslaProperty }

where CslaProperty is a template. It's sort of like adding inheritance to Properties. I'd also like to be able to take it further so you could say...

public string A
{
    get;
    set
    {
        if (value == null)
            value = "";
        @templateBase = value;
    }
}

This would stop the really annoying thing about automatic properties where you use them, then you want to make a minor change and have to go to the trouble of making a full property