C# 4.0

[Dave Parker]

Shame neither of them act as a kind of write-once property (other than readonly when set in a constructor) so you can't have constant DateTimes and things.

[MrPlankton]

You of course would write it, to handle that case.

MrPlankton

[Jamie Nordmeyer]

No it's not. I'm not asking how to solve anything. Simply a feature ideas request. And since you're the only one so far to suggest this is a programming question, you're the only one who thinks so.

Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA

[Jamie Nordmeyer]

Here's an example of what I think he's saying:

public void DoSomething(const Employee emp)
{
emp.Age = 32; // This would not compile.
}

An object is passed by reference, so its properties are settable. You don't want to make the Age property read only, because normally, you want the consumer to be able to set it. But what if DoSomething was meant to be a final validation, and you didn't want anything in the object to change, because it could mess up state elsewhere? The const keyword would allow the developer to leave a property or field writable, but still be able to restrict when it could be written to.

Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA

[Pawel Krakowiak]

MrPlankton wrote:

You of course would write it, to handle that case.

I thought so. :) Then it's the same as with the current lack of optional method arguments - you have to write overloads and people complain. Now you would have to write void methods...

[Hooga Booga]

Free beer!

[User 3728064]

really interesting!

[Giampaolo Papotti]

I strongly Agree! C# cut-offs from c++ were really too deep. cons keyword (both on parameters and members signatures) shoud be a MUST in any oo language. 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....)

[pherschel]

I'd like to see built in threading. Example: int x = CalcXDataValues() &; <- run as thread int y = CalcYDataValues() &; int z = x + y; // will not execute until x and y are set!

- Pete

[Anubisasc]

I would like to be able to do something like this:

const string[] constantArray = {
"String1",
"String2",
"String3"
};

Right now you can only create a static read only array.

[MrPlankton]

Well you could cast it to the method you want even if there is no left side argument. (int)functA("stuff"); I'm just saying having the return type as part of the signiture would be nice to have from time to time.

MrPlankton

[grgran]

What would you expect 'const' to do? Would it just be the programmers promise not to change the contents of the object (generating an error if an assignment was attempted)? Would it also be able to determine if a method call on the object changed the state of the object and generate an error? If const is accepted as a parameter keyword should it also be accepted as a method modifier? How would optional parameters differ from the current params keyword?

[Pawel Krakowiak]

MrPlankton wrote:

I'm just saying having the return type as part of the signiture would be nice to have from time to time

I know, I've been there myself. ;)

[Donkey Master]

Ok, I think I get it. So, I would be able to call methods and get properties and fields, but forbidden from setting fields and properties. Well, there are still the methods to change the data, so I guess that optimization-wise, this doesn't help. So, it's mostly syntactic sugar, a contract constraint. I'd put it in the same category as varargs, in terms of usefulness. You say that VB.NET has this feature today? How does it work when you import a VB.NET library to another language, like C#?

"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra

[grgran]

I'd like to see operator overloading supported in Interfaces, but this obvious has problems for languages that don't support op overloading. Here's what I'm thinking interface INumeric { ... overloads for +, -, /, *, remainder, (others) } class stats<T> where T:INumeric { ... methods to calculate staticial values on type T } This doesn't have to be done with interfaces (that just seems easiest). If all the numerics shared a common base class that would also be ok. I realize that this can be done with out op overloading (using only method calls), but I'd like to see it build-in so the standard types implement a basic set of operators, and users could implement their own (possibly) wacky types. That way the possibly complex methods used to calculate need only be written once. Consider, calculating Navier–Stokes equations over a large region, then as you drill down into a small region you find that you need more precision than the ~15 of doubles, so you write a high precision class that is much slower but provide the precision required. If there were a natural way to create such a class then it could just be plugged in via generics rather than requiring a bunch of complex equations to be rewritten for the new type or for method (rather than operator) expansion. Ok, that's enough wackiness for one day

[Gonzalo Brusella]

Default initialization on auto-implemented properties!!

I'm on a Fuzzy State: Between 0 an 1

[Sunny Ahuwanya]

Pawel Krakowiak wrote:

I think of them as of an improvement and use them. Smile

Can anyone explain to me how extension methods are an improvement? Besides helping to sell LINQ and encouraging programmers to write code in a non-portable, non object oriented manner, what is the point of extension methods?

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

[Kenneth Kasajian]

I have 5 that I want Basic stuff: 1. I'd like compile-time calculation and compile-time execution support. I'd like to have a compile-time assert, as well as simple calculations. I don't want to do calculations at runtime on static data I have a compile time. 2. I'd like to see language support for mixins. 3. I'd like to be able to write "const-correct" code the way I can in C++. I'd like to be able to mark a method read-only so that I know it doesn't modify the data. I'd like to be able to have a read-only object and pass it to other functions knowing that they cannot modify it. This really helps when reading other people's code, too, 'cause you can easily determine their intent. The following I think are features that the language will eventually have -- mark my words. 1. Language support for mocking. For instance, I should be able to instantiate an interface and get some dummy default implementation. This will help with stubbing. And I should be able to configure the mock in a simple way to do some other "basic" functions. 2. Language support for unit testing. I realize that everyone's thinking why, 'cause NUnit works, etc. But if you allow your mind to wonder why it would be like to have language support for Unit Testing, you can imagine some interesting possiblities. For instance, how about methods won't compile unless they have tests. Or if every path doesn't isn't executed, then you get a compiler warning. Maybe those aren't the best examples, but smarter people can come up with something more interesting.

ken@kasajian.com / www.kasajian.com

[Sunny Ahuwanya]

There are so many things wrong with extension methods that I *still* get baffled how the geniuses at M$ included that as a feature. I guess LINQ must have been a HUGE thing for every team to bend their libraries and languages to 'force' it to fit in. I just want the option not to use it or make me use it in the "good way". This is just like the way you could set option strict in classic VB. Luckily almost all Microsoft extension methods come with in their exclusive namespaces. So all I have to do now is not include those namespaces BUT that doesn't prevent some other genius at XYZ company to pack extension methods with regular methods in their libraries and forcing ME to write bad code. Chip on my shoulder :)

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

[S Senthil Kumar]

Let's say you are using a library with the following code

// Assembly SomeLib.dll

class C
{
void someMethod() const {...}
}

and the code using it looks like this

// Assembly App.exe

void usingMethod(const C obj)
{
obj.someMethod(); // ok, because someMethod is const
}

Now let's say a new version of SomeLib.dll comes out and in that version, someMethod() becomes non-const. With C++, App.exe would require recompiling with the modified header file, and the compiler would be able to flag the error in usingMethod (non const method call on a const object). With .NET and binary compatibility, there's no recompiling necessary - you just drop in the new DLL and now the const guarantee is broken. It would be a silent breaking change, unless there is a runtime check.

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