|
Vikram A Punathambekar wrote: but how would you implement a runtime check?
The fact that a const method is being called will have to be embedded in the IL and the type verifier will have to lookup the called method's metadata (atleast once) to know whether it is still const. It's doable in theory, but will probably be impracticably slow in practice.
And it'll probably have to throw an exception if it finds a mismatch.
I wish there was a better mechanism for const though - even in C++, I hated the cascading effect of const. In a way, it is like checked exceptions in Java i.e., throw a new exception in a method at the lowermost level, and the throws clause of every method that directly or indirectly calls it will have to modified.
|
|
|
|
|
Yeah, that's how I thought it would be implemented, if it were.
S. Senthil Kumar wrote: in C++, I hated the cascading effect of const
I can't see how you could make it non-cascading: if a const method were to call a non-const method (which then proceeds to modify the object), that would totally break the contract it promises its calling methods.
S. Senthil Kumar wrote: the throws clause of every method that directly or indirectly calls it will have to modified
Only if the excception is not handled.
I am a big fan of Java's checked exceptions. 
Cheers,
Vıkram.
"You idiot British surprise me that your generators which grew up after Mid 50s had no brain at all." - Adnan Siddiqi.
|
|
|
|
|
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)?
|
|
|
|
|
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  ; 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.
|
|
|
|
|
As for the optional parameters, they say that method overloads work better in that respect. I got used to it and don't complain. Maybe one advantage (trying to agree with MS) I can see is that when you debug your C# code the debugger (Call Stack) will show you which overload was called exactly, while it may not be apparent if a default parameter value was used...
|
|
|
|
|
maybe another advantage is that loads of defaulted parameters would slow a simple call down, but using overloaded functions it would not have to push all those unused parameters onto the stack, so it would go faster.
|
|
|
|
|
I am astounded they don't support const parameters yet. Naturally, if they support const parameters, they will almost certainly have to support const methods.
I think const parameters are one of the best things about C++ that got dropped out in C#.
Cheers,
Vıkram.
"You idiot British surprise me that your generators which grew up after Mid 50s had no brain at all." - Adnan Siddiqi.
|
|
|
|
|
The good answer to 'constness' is spec#. The 'constness', the 'nonnullness', the 'checkedexceptionness' , the 'immutabilityness' etc ... are all describable with contracts.
I think Spec# will be a real revolution in the .NET world. In fact the .NET infrastructure should evolve to include contract metadata so that every .NET language will manage contracts in a similar way.
Try it here http://research.microsoft.com/SpecSharp/[^] ...
and cry because I am sure that c#4 won't include spec# 
|
|
|
|
|
higelino wrote: I am sure that c#4 won't include spec#
Yes, I bet it won't. Unfortunately.
Kevin
|
|
|
|
|
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?
|
|
|
|
|
I miss const more than optional parameters. I did VB .NET for a year. It has optional parameters and it put me off them really. Even though prior to this I've been a C++ dev and didn't seem to mind them then! Perhaps it was just the way they were used in VB? Or maybe I've just changed my taste?
Kevin
|
|
|
|
|
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
|
|
|
|
|
Jamie Nordmeyer wrote: C# 4.0
I haven't heard anything about it.
Jamie Nordmeyer wrote: return min, max;
That syntax wouldn't be a good choice, because of the comma operator.
I would just return an array of int. Though the only place I do that is a routine that parses a string to get a latitude and longitude (doubles in this case).
|
|
|
|
|
PIEBALDconsult wrote: That syntax wouldn't be a good choice, because of the comma operator.
It'd certainly take some work on the part of the parser developers at Microsoft, but it'd still be useful in my humble opinion. What if I wanted to return an integer, 2 strings, and a DateTime? Today, I'd just use a struct or out parameters. Easy enough. It'd just be NICE to be able to return everything. Like the ?? operator. Not necessary, but still useful.
Again, just my humble opinion. 
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan
Portland, Oregon, USA
|
|
|
|
|
PIEBALDconsult wrote: I would just return an array of int. Though the only place I do that is a routine that parses a string to get a latitude and longitude (doubles in this case).
I would return a System.Drawing.PointF for latitude/longitude values, or if I needed lat/long
minutes and seconds, I would make a struct for it. 
~Ribose
|
|
|
|
|
Why do you need this feature since currently object, array and many other types can be returned or passed by reference.
TOMZ_KV
|
|
|
|
|
Sigh. As I've said above numerous times, it's not NEEDED, it'd just be nice. The ?? operator is not needed. But it's a great shortcut. The foreach construct isn't needed. But it's a great shortcut (you could do the same thing with a while loop, checking whether the MoveNext method of the enumerator returns false). Same with the idea of tuples. I'd rather be able to return 3 or 4 values than have to deal with the messiness of out parameters, or having to define multiple structs to handle each return combination that I might need.
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan
Portland, Oregon, USA
|
|
|
|
|
Actually, foreach is needed.
Without foreach, you can't guarantee that the Enumerable pattern is followed. You don't expect developers to consistently follow the pattern using a for or while loop.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Surely without foreach you'd just be in the same position as Java was (pre v1.5?) where you have to make a call to getIterator() and then loop through that.
It's much more unfriendly than foreach but it still does the same thing
Russ
|
|
|
|
|
We have the anonymous type. Create an anonymous type structure in your method and return it to a var local variable.
|
|
|
|
|
How about a function's return type being part of it's signature and not just the arugment list;
so
int functA(string abc);
string functA(string abc);
does not cause a compile error when they are in same class.
MrPlankton
|
|
|
|
|
Yeah, I've often thought it was kind of dumb that languages didn't do this in the first place. I think the reason though is in how the parameters are wound on to the stack. I agree, though, that if they can make it work, it'd be worth it.
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan
Portland, Oregon, USA
|
|
|
|
|
You use to be able to do this in c++.
MrPlankton
|
|
|
|
|
You would have to make sure that you correctly assigned the return value in order for this to work, right?
eg:
int x = funcA( "blah" )
tells the compiler to use the version that returns int, but what about these calls?
<br />
funcA( "blah");<br />
object o = funcA( "test" );<br />
They're ambiguous calls and the compiler can't help you any more.
|
|
|
|
|
It's been awhile since I did any c++, but I believe you would get a compile warning with Borlands old c++ compiler and then it would take it's best guess. Casting the function call would make the compiler happy.
They could do the same with next version c#.
MrPlankton
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
