C# 4.0
-
harold aptroot wrote:
Why const? What will it even do besides limit the programmer in the usage of said parameters?
Well, that's kind of the point. You want to limit the usage of const parameters to minimize side-effects.
-
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...
-
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:
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
-
So now that C# 4.0 is being talked about, I was wondering what people thought would be good additions to the language. Sorry if this is a repost, but I went through several pages, and didn't see anything, so... What I'd frankly love to see would be tuples. Rather than having to use multiple 'out' parameters, you'd just return multiple values:
public int,int MinMax(int[] numbers)
{
int min, max;
// Code to calculate min/maxreturn min, max;
}What do you think? What would be good for the next version?
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
I'd like to see member variables treated as if they were in a class-lifetime 'using' statement. I miss the deterministic destructor from c++, but this would at least allow me to put the class in a using statement and have its member variables' dispose methods called implicitly.
-
I'd like to see member variables treated as if they were in a class-lifetime 'using' statement. I miss the deterministic destructor from c++, but this would at least allow me to put the class in a using statement and have its member variables' dispose methods called implicitly.
-
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
Thanks for the explanation, but how would you implement a runtime check? And what would it do - throw an exception that the called code has changed the object despite its (earlier) promise not to?
Cheers, Vıkram.
"You idiot British surprise me that your generators which grew up after Mid 50s had no brain at all." - Adnan Siddiqi.
-
I saw someone comment on that on another forum. Basically, you'd have something like this (using his sample syntax):
int? x = Company?.Person["Bob"]?.Age;
If Company or Company.Person["Bob"] were null, then x would be set to null, rather than getting an exception. I likes.
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
Jamie Nordmeyer wrote:
I saw someone comment on that on another forum.
Daniel Grunwald, TheCodeKing and myself came up with that here[^]. You're missing the final part tho, which is a ?? operator to act as the "default": int? x = Company?.Person["Bob"]?.Age ?? null; Of course setting null as the "default default" would also work and be handy.
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Check out my blog! ) |)””’) piHole.org -”-”-
-
PIEBALDconsult wrote:
and return [w,h,d] ?
Yeah, keep it distinct from blocks, initializers, etc.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
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
We have the anonymous type. Create an anonymous type structure in your method and return it to a var local variable.
-
Thanks for the explanation, but how would you implement a runtime check? And what would it do - throw an exception that the called code has changed the object despite its (earlier) promise not to?
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:
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.
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
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
Who says object-orientation is the sole valid way to write code? Object-orientation can get in the way when something simpler would suffice to get the job done. Extension methods allow you to add a great deal of expressiveness to your code, extend base types you don't have direct control of to provide a cleaner API, etc. etc. Whats with all the hostility towards useful language features and non-object-orientedness? Objects don't solve every problem. Portability? Where are you going to "port" a C# or VB.NET app to...they only run on the .NET platform anyway. Use the features for what they are. As a programmer, your job is to provide solutions to business problems in the most effective, efficient, maintainable way possible...don't get so hung up on all the "rules" and "regulations" of OOP...objects arn't the only option.
-
Pawel Krakowiak wrote:
add new functionality to the existing classes
They do nothing of the sort!
They absolutely do! Look at IEnumerable...EVERY type that implements IEnumerable DOES INDEED get the full functionality of all extension methods written for IEnumerable (so long as the proper using statement(s) are included). You don't have to "implement" the extension methods on each class that implements IEnumerable...the extension methods absolutely do add new functionality without you having to do any extra implementation. And that functionality is accessed through class INSTANCES...not static methods or utility types. You anti-progressive types drive me nuts sometimes...get off your high horse and USE the tools at your disposal. You might find that you actually like them.
-
On Portability: 1) Imagine if I had to port some C# code from one framework/platform to another. Before C# 3.0, I'd had to make sure I have compatible libraries in the new framework. But now, I also have the added headache of figuring out where ALL the referenced extension methods in the code are and make sure they exist in the new framework (or write equivalent ones). It doesn't help that extension methods share the same dot notation with regular methods. I can't tell what an extension method is just by looking at the call. I'd have to write some tool that will check all referenced assemblies to point out the extension methods in the code. 2) Let's say I'm using LINQ's IEnumerable.Where extension method on a collection class someone else wrote, BUT I didn't realize the other developer had included a .Where regular method that returns an IEnumerable. My code will compile superbly without any warnings. The best part is that this code will work for months until THE CONDITION that differentiates the developer's .Where method and the LINQ's .Where method occurs. On Object Orientedness: Developer A uses List.SingleOrDefault() extensively, developer B creates a new class derived from List but would like .SingleOrDefault() to work a little differently so that all the pre-existing code will work properly with objects derived from his new class. He's stuck. :(
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
The methods implemented as part of IEnumerable are now intrinsic to the .NET framework. Any decent developer would avoid using identifiers already used in the framework. Your argument about IEnumerable.Where is the same as saying Developer B creates a new class called String... Simple solution, don't do that. Almost any language feature can be missused. Don't missuse them.
-
How about a way to check against all values in an array or enumerabale at once with perhaps the keyword 'any' like below.
int[] supportedValues = new int[] { 3, 4, 5 }
int x = 4;if (x == any supportedValues)
{
// Do something.
}Instead of:
int[] supportedValues = new int[] { 3, 4, 5 }
int x = 4;
bool xIsSupported = false;foreach (int value in supportedValues)
{
if (x == value)
xIsSupported = true;
}if (xIsSupported)
{
// Do something.
}Good idea?
Why not use the
Containsextension method? It's almost similar to your syntax.IEnumerable arr = new int\[\] { 1, 2, 3 }; int x = 4; if (arr.Contains(x)) { Console.WriteLine("Present"); }Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
Sunny Ahuwanya wrote:
non-portable, non object oriented manner
Hmm, that's interesting. Is it not part of the ECMA spec? Considering there's no runtime support required for extension methods, I can't see any other portability concerns. Or maybe you are considering them non-portable because the calling code won't compile without the presence of the source code containing the extension methods? And yeah, they are non object oriented if you consider static methods in a static class non-object oriented as well.
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
This raises a good point about extension methods. They are not object oriented. If someone wants to write an extension method, then they should write a subclass to the object you want. Then add the desired methods. But, it sounds like LINQ is a (very) popular feature. And, the only way to support LINQ is by extension methods. Then, maybe the question should be is should MS not allow the public (those not writing directly for MS C#) to create extension methods? Keep them internal to the Microsoft C# team for specific requirements of the language (like LINQ).
-
I do sort of like the idea but isn't a function by definition a thing that only returns a single value? Maybe we need anonymous returns instead so that you define a struct on the fly, thus returning a single entity that contains the multiple values. public {Max int, Min int} MinMax(int[] numbers) { int min, max; // Code to calculate min/max return {min, max}; } called with var v= MinMax(myArray); system.out.println(v.Min); system.out.println(v.Max); otherwise you'd end up having to create something wierd like this to get the values back int min, max = MinMax(myArray); Russell
You could consider the tuple to be a single value. The single value is the tuple as a whole thing. public [int,int] MinMax(int[] numbers) { int min, max; // Compute min and max return tuple[min,max]; } tuple[int,int] result = MinMax(new[] { 1, 2, 3, 5, 8, 13 }); If tuples were added to C# 4.0, I think they should be added properly, with a native syntax for defining them. Perhapse even support for "anonymous" tuples akin to var: public [int,string,string,DateTime] TupleFunc() { return tuple[1, "String 1", "String 2", DateTime.Now]; } tuple result = TupleFunc(); int number = result[0]; string firstString = result[1];
-
Pawel Krakowiak wrote:
add new functionality to the existing classes
They do nothing of the sort!
PIEBALDconsult wrote:
They do nothing of the sort!
string lookingFor = "Wash";
lookingFor.ToSqlLike(SqlLikePlacement.Front); // returns "Wash%"
lookingFor.ToSqlLike(SqlLikePlacement.Middle); // returns "%Wash%"
lookingFor.ToSqlLike(SqlLikePlacement.End); // returns "%Wash"I understand I missed something and the above code is possible without extension methods and without creation of a new class?
-
How about a way to check against all values in an array or enumerabale at once with perhaps the keyword 'any' like below.
int[] supportedValues = new int[] { 3, 4, 5 }
int x = 4;if (x == any supportedValues)
{
// Do something.
}Instead of:
int[] supportedValues = new int[] { 3, 4, 5 }
int x = 4;
bool xIsSupported = false;foreach (int value in supportedValues)
{
if (x == value)
xIsSupported = true;
}if (xIsSupported)
{
// Do something.
}Good idea?
-
Who says object-orientation is the sole valid way to write code? Object-orientation can get in the way when something simpler would suffice to get the job done. Extension methods allow you to add a great deal of expressiveness to your code, extend base types you don't have direct control of to provide a cleaner API, etc. etc. Whats with all the hostility towards useful language features and non-object-orientedness? Objects don't solve every problem. Portability? Where are you going to "port" a C# or VB.NET app to...they only run on the .NET platform anyway. Use the features for what they are. As a programmer, your job is to provide solutions to business problems in the most effective, efficient, maintainable way possible...don't get so hung up on all the "rules" and "regulations" of OOP...objects arn't the only option.
Interesting. I thought that C# originally was to be more OO than C++. Even in C++, you can write a completely procedural language type program (the C language). Maybe, Microsoft, in their zeal to make it easier to write software, is turning C# into an all in one language where you can get a job done any way you want. Maybe, at some later date, the keyword class will not be deprecated (not a first class item). Already, the anonymous type and var keyword are reducing the OO aspect of the language. Then, maybe, the hardcore OO engineers will move to Java.
-
They absolutely do! Look at IEnumerable...EVERY type that implements IEnumerable DOES INDEED get the full functionality of all extension methods written for IEnumerable (so long as the proper using statement(s) are included). You don't have to "implement" the extension methods on each class that implements IEnumerable...the extension methods absolutely do add new functionality without you having to do any extra implementation. And that functionality is accessed through class INSTANCES...not static methods or utility types. You anti-progressive types drive me nuts sometimes...get off your high horse and USE the tools at your disposal. You might find that you actually like them.