The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.
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.
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.
It is more that .NET 2.0 provide the exact construct as required to perform the action without the need for a language update. I am not saying it is hard to master but I am constantly seeing instances of persons requesting features that are already supported.
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....)
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....)
I had heard that proper run-time const support in the clr was far too hard or expensive, and providing a weak const keyword in c# (like c++ has got) without properly enforcing it in the clr would just be misleading.
Shame though; I would have liked proper const guarantees in the clr.
Because if you're providing an interface, you provide a contract with the people who use that interface. If I write a library, I can use const to tell a user when they can trust my code not to change their stuff.
No longer a Microsoft MVP, but still happy to answer your questions.
publicvoid 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
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.
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra