C# 4.0
-
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
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
-
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 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
-
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
Default initialization on auto-implemented properties!!
I'm on a Fuzzy State: Between 0 an 1
-
Sunny Ahuwanya wrote:
I think they already degraded the language in C# 3 by adding extension methods
I think of them as of an improvement and use them. :)
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
-
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 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.
-
Oh, well then... Treat the
usingdirective as an error. While you're at it, require full attribute names.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 wrote:
The methods themselves would have to be declared const, just like in C++.
Yeah, I wrote that myself, without reading your post. :doh:
S. Senthil Kumar wrote:
if a method declared const in v1 of the library became non const in v2, the "constness" guarantee will get broken (unless there is a runtime check).
I'm not sure I understand, could you please explain?
Cheers, Vıkram.
"You idiot British surprise me that your generators which grew up after Mid 50s had no brain at all." - Adnan Siddiqi.
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
-
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
Sunny Ahuwanya wrote:
There are so many things wrong with extension methods
Care to list some of them? I get that they can pollute the list of methods in a class and can cause calls to unintended methods, what else do you find wrong?
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
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
-
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 don't know what I'd put in, but I know what I'd 'take out'. I'd restrict the use of the 'var' keyword to the Linq domain, only. I see major abuse coming, and I don't relish maintaining code which uses the 'var' keyword in a profligate fashion. D. T. Doutel
-
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
-
Sunny Ahuwanya wrote:
A good programming language need not be updated every three years.
True... but we're talking about C#. :-\ </cheapshot>
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
C# is only a prototype to find out what people want, the next language will take those concepts and be the "real" product. :-D
-
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?
foreach (int value in supportedValues) { if (x == value) { xIsSupported = true; break; //why keep on when you are done? :confused: } }
-
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
What every language needs, and what every virtual language lacks: the ability to do inline assembly where necessary with the understanding that makes your code non-portable. For some stupid reason, I'm currently working on a project that is testing hardware at a very low (sometimes pre-boot) level- but the primary languages seem to be VB.NET and C#. It's highly frustrating. I realize this would be dangerous and that most programmers out there aren't at a level where they could make proper use of it, but having NO capability for it is ridiculous.
-
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
Yeah, a bad idea implemented poorly. What I finally decided to do was to put each Extension Method I write (I have four, none of them Earth-shattering) in its own namespace, so you only get what you ask for. I don't use Linq either. The only reason to use .net 3.5 is HashSet, and even that is underwhelming -- no operators! I'm guessing they only added it because they use it in Linq and didn't want to be accused of using undocumented features (again).
Sunny Ahuwanya wrote:
forcing ME to write bad code.
Use them as regular static methods.
-
Then so be it, in this case you would simply remove the "const" if it were there, meaning that it shouldn't really have been there to start with
Can you remove the code if you have to satisfy an interface definition that contains the const keyword? ;)
I've heard more said about less.
-
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
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
-
I don't know what I'd put in, but I know what I'd 'take out'. I'd restrict the use of the 'var' keyword to the Linq domain, only. I see major abuse coming, and I don't relish maintaining code which uses the 'var' keyword in a profligate fashion. D. T. Doutel
Here here!
varshould only be used when you don't know the type! -
Can you remove the code if you have to satisfy an interface definition that contains the const keyword? ;)
I've heard more said about less.
-
I'd really really really like to see absolutely no changes whatsoever. Seriously.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
I'd want to back up half a step.