C# 4.0
-
I don't think people separate them, because they are so tightly integrated. C# is a language, but it is tightly integrated with the .NET framework. Thats part of what makes it such a great platform...the C# compiler simplifies the use of the framework. Its the same with the Singularity project. Their version of C# was even more advanced than anything we have today. The C# from Singularity was a blend of C# 2.0, Cω, Spec#, with some additional features none of them had. In particular, Singularity C# made message contracts first class language citizens similar to interfaces. The C# from Singularity is far from portable in the sense your talking about...it was tightly integrated with the Singularity platform. Its also extremely powerful, and its features will probably find their way into the public C# spec at some point (woot!). When it comes to portability between different frameworks like Mono. C# is an open, standard specification, and each version can be implemented by any third party...they just tend to be a bit delayed. I know for a fact that Mono 2.0 will include a fully compliant C# 3.0 compiler, which means code you may have written over the past year (it hasn't even been a year yet) will be portable to Mono. That includes LINQ, Extension methods, anonymous types, etc. If you require cross-platform portability, I don't think the problem is that its not possible...you just can't take advantage of new language versions until the third-parties catch up.
Jon Rista wrote:
C# is a language, but it is tightly integrated with the .NET framework.
Is there any keyword in the C# language that suggests the use of a particular framework? What is to stop any one with the talent and time to write a C# compiler/framework that targets a currently unsupported platform?
Jon Rista wrote:
you just can't take advantage of new language versions until the third-parties catch up.
So what do i do if I need to port the code right now?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
Jon Rista wrote:
C# is a language, but it is tightly integrated with the .NET framework.
Is there any keyword in the C# language that suggests the use of a particular framework? What is to stop any one with the talent and time to write a C# compiler/framework that targets a currently unsupported platform?
Jon Rista wrote:
you just can't take advantage of new language versions until the third-parties catch up.
So what do i do if I need to port the code right now?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
"Is there any keyword in the C# language that suggests the use of a particular framework?" - Sunny Well, LINQ syntax comes to mind. The C# compiler translates LINQ into expression trees, which are a part of the .NET 3.5 framework. LINQ is syntactic sugar for a complex framework feature. Seems to be bound to a particular framework to me. Which is all good with me...I'd rather write LINQ syntax than build expression trees manually. "What is to stop any one with the talent and time to write a C# compiler/framework that targets a currently unsupported platform?" - Sunny Never said it would stop anyone...hence my discussion of Mono. :rolleyes: "So what do i do if I need to port the code right now?" - Sunny If you needed to write portable code, why did you dive in and use C# 3.0? Come on man, have some common sense. If A, then B. If you need portable code, then use a portable language version. It's a simple concept. Don't go all about being the antagonist nay-saying useful language features that, apparently, you want to use, and are just miffed that the third-party projects like Mono havn't caught up with yet. It's like your a little kid, "If I can't have it, no one will!!"
-
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
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.
-
Bad example. How is that better than:
lookingFor = "%" + lookingFor ; lookingFor = lookingFor + "%" ; lookingFor = "%" + lookingFor + "%" ;The standard way is much clearer (at least in this case).PIEBALDconsult wrote:
How is that better than: lookingFor = "%" + lookingFor ; lookingFor = lookingFor + "%" ; lookingFor = "%" + lookingFor + "%" ; The standard way is much clearer (at least in this case).
I was using the example code to filter SubSonic queries (which look much like LINQ extension methods) and it definitely looks better there. By the way, you know that C# strings are immutable and the above code you provided creates additional string objects just to discard them right after they are created and make them wait for the garbage collector to do its job? ;) Very inefficient, I'd say.
-
"Is there any keyword in the C# language that suggests the use of a particular framework?" - Sunny Well, LINQ syntax comes to mind. The C# compiler translates LINQ into expression trees, which are a part of the .NET 3.5 framework. LINQ is syntactic sugar for a complex framework feature. Seems to be bound to a particular framework to me. Which is all good with me...I'd rather write LINQ syntax than build expression trees manually. "What is to stop any one with the talent and time to write a C# compiler/framework that targets a currently unsupported platform?" - Sunny Never said it would stop anyone...hence my discussion of Mono. :rolleyes: "So what do i do if I need to port the code right now?" - Sunny If you needed to write portable code, why did you dive in and use C# 3.0? Come on man, have some common sense. If A, then B. If you need portable code, then use a portable language version. It's a simple concept. Don't go all about being the antagonist nay-saying useful language features that, apparently, you want to use, and are just miffed that the third-party projects like Mono havn't caught up with yet. It's like your a little kid, "If I can't have it, no one will!!"
Jon Rista wrote:
Well, LINQ syntax comes to mind. The C# compiler translates LINQ into expression trees, which are a part of the .NET 3.5 framework. LINQ is syntactic sugar for a complex framework feature. Seems to be bound to a particular framework to me.
The foreach keyword binds to .NET's IEnumerable pattern, the lock keyword binds to .NET's Monitor.Enter/Monitor.Exit methods. There is nothing new in the C# 3 compiler translating LINQ's query expressions to .NET 3.5's expression trees. Anybody developing a compiler targeting a particular framework will decide how they want these keywords to work. Do they bind to a framework library? Do they generate their own code? etc.
Jon Rista wrote:
Come on man, have some common sense. If A, then B. If you need portable code, then use a portable language version. It's a simple concept. Don't go all about being the antagonist nay-saying useful language features that, apparently, you want to use, and are just miffed that the third-party projects like Mono havn't caught up with yet. It's like your a little kid, "If I can't have it, no one will!!"
LOL. You are right, but bear in mind that developers routinely port code someone else wrote. If I'm given a task to port C# 3 code to a C# 2 platform. I'm not going to sit around waiting for the third party platform to catch up. I should be able to do it because the .NET framework for both platforms are binary compatible. If I run into expression trees and Linq query syntax. I'll simply write a substitute class that performs the same functionality (provided the original author properly packaged those statements in classes). You have said good things about C# 3 and you have been correct (I personally love lambda expressions), however, we should call a spade a spade and that black sheep is called Extension methods. If their is something wrong with a product, the consumers have every right to voice their concerns and my concern is nobody except Microsoft knows how to properly use Extension methods. If you notice they: a) Package extension methods in exclusive namespaces. b) Extension methods usually implement an algorithm (not a function) c) Don't tell anyone else how to properly use it (I for one haven't seen a best practices paper on extension methods) The goto keyword is in every major programming language but it has been repeatedly advised not to be used unless y
-
Jon Rista wrote:
Well, LINQ syntax comes to mind. The C# compiler translates LINQ into expression trees, which are a part of the .NET 3.5 framework. LINQ is syntactic sugar for a complex framework feature. Seems to be bound to a particular framework to me.
The foreach keyword binds to .NET's IEnumerable pattern, the lock keyword binds to .NET's Monitor.Enter/Monitor.Exit methods. There is nothing new in the C# 3 compiler translating LINQ's query expressions to .NET 3.5's expression trees. Anybody developing a compiler targeting a particular framework will decide how they want these keywords to work. Do they bind to a framework library? Do they generate their own code? etc.
Jon Rista wrote:
Come on man, have some common sense. If A, then B. If you need portable code, then use a portable language version. It's a simple concept. Don't go all about being the antagonist nay-saying useful language features that, apparently, you want to use, and are just miffed that the third-party projects like Mono havn't caught up with yet. It's like your a little kid, "If I can't have it, no one will!!"
LOL. You are right, but bear in mind that developers routinely port code someone else wrote. If I'm given a task to port C# 3 code to a C# 2 platform. I'm not going to sit around waiting for the third party platform to catch up. I should be able to do it because the .NET framework for both platforms are binary compatible. If I run into expression trees and Linq query syntax. I'll simply write a substitute class that performs the same functionality (provided the original author properly packaged those statements in classes). You have said good things about C# 3 and you have been correct (I personally love lambda expressions), however, we should call a spade a spade and that black sheep is called Extension methods. If their is something wrong with a product, the consumers have every right to voice their concerns and my concern is nobody except Microsoft knows how to properly use Extension methods. If you notice they: a) Package extension methods in exclusive namespaces. b) Extension methods usually implement an algorithm (not a function) c) Don't tell anyone else how to properly use it (I for one haven't seen a best practices paper on extension methods) The goto keyword is in every major programming language but it has been repeatedly advised not to be used unless y
I'm still not convinced that extension methods are this evil black sheep. Were beyond issues of portability now, and into issues of coding preference, I think. a) Package extension methods in exclusive namespaces. aa) Where would you package them, and why would that place be better than an exclusive namespace? b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be? c) Don't tell anyone else how to properly use it. cc) Who defines what proper use is? In what usage instances is one way proper, and what other instances is it improper? Again, I think a little common sense works here. Extension method best practice #1: SIDE EFFECT FREE. Follow that rule, and I think your use of extension methods will be quite enjoyable, regardless of where they are packaged or whether they implement an algorithm or....well, isn't that it...algorithms? Another interesting tidbit about C# 3.0/.NET 3.5. Since .NET 3.5 is just a bunch of new API's on top of the .NET 2.0 runtime, and C# is a translator as well as a compiler, the end result is still CLI that is compatible with .NET 2.0. So long as the appropriate assemblies are available, a .NET application written with C# 3.0/.NET 3.5 should run on a system with only .NET 2.0 installed. Sounds pretty portable to me. ;) Speaking of goto, I use it in two cases:
foreach (...)
{
foreach (...)
{
foreach (...)
{
if (exitCondition)
goto DoneWithLoops;
}
}
}DoneWithLoops:
// Finish upThats a lot cleaner than having a bunch of flags that have to be checked in every loop if a complete exit from all loops is needed. C# translates complete exits from nested loops into a goto anyway in a lot of cases, so the above code is whats going to happen anyway.
switch (...)
{
case 1:
{
// Do something that augments default
goto default;
}
case 2:
{
// Do something unique
break;
}
default:
{
// Do common stuff
break;
}
} -
I'm still not convinced that extension methods are this evil black sheep. Were beyond issues of portability now, and into issues of coding preference, I think. a) Package extension methods in exclusive namespaces. aa) Where would you package them, and why would that place be better than an exclusive namespace? b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be? c) Don't tell anyone else how to properly use it. cc) Who defines what proper use is? In what usage instances is one way proper, and what other instances is it improper? Again, I think a little common sense works here. Extension method best practice #1: SIDE EFFECT FREE. Follow that rule, and I think your use of extension methods will be quite enjoyable, regardless of where they are packaged or whether they implement an algorithm or....well, isn't that it...algorithms? Another interesting tidbit about C# 3.0/.NET 3.5. Since .NET 3.5 is just a bunch of new API's on top of the .NET 2.0 runtime, and C# is a translator as well as a compiler, the end result is still CLI that is compatible with .NET 2.0. So long as the appropriate assemblies are available, a .NET application written with C# 3.0/.NET 3.5 should run on a system with only .NET 2.0 installed. Sounds pretty portable to me. ;) Speaking of goto, I use it in two cases:
foreach (...)
{
foreach (...)
{
foreach (...)
{
if (exitCondition)
goto DoneWithLoops;
}
}
}DoneWithLoops:
// Finish upThats a lot cleaner than having a bunch of flags that have to be checked in every loop if a complete exit from all loops is needed. C# translates complete exits from nested loops into a goto anyway in a lot of cases, so the above code is whats going to happen anyway.
switch (...)
{
case 1:
{
// Do something that augments default
goto default;
}
case 2:
{
// Do something unique
break;
}
default:
{
// Do common stuff
break;
}
} -
PIEBALDconsult wrote:
How is that better than: lookingFor = "%" + lookingFor ; lookingFor = lookingFor + "%" ; lookingFor = "%" + lookingFor + "%" ; The standard way is much clearer (at least in this case).
I was using the example code to filter SubSonic queries (which look much like LINQ extension methods) and it definitely looks better there. By the way, you know that C# strings are immutable and the above code you provided creates additional string objects just to discard them right after they are created and make them wait for the garbage collector to do its job? ;) Very inefficient, I'd say.
Yes, I know that, but the implementation of SqlLike (or whatever) may be no better, and adds a function call as well (which may or may not get inlined). And perhaps pre-condition checking as well. Plus that's only true of the last example. There's no way to tell which is "more efficient" from just looking at the examples, and such concerns are likely to be needless anyway.
-
I'm still not convinced that extension methods are this evil black sheep. Were beyond issues of portability now, and into issues of coding preference, I think. a) Package extension methods in exclusive namespaces. aa) Where would you package them, and why would that place be better than an exclusive namespace? b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be? c) Don't tell anyone else how to properly use it. cc) Who defines what proper use is? In what usage instances is one way proper, and what other instances is it improper? Again, I think a little common sense works here. Extension method best practice #1: SIDE EFFECT FREE. Follow that rule, and I think your use of extension methods will be quite enjoyable, regardless of where they are packaged or whether they implement an algorithm or....well, isn't that it...algorithms? Another interesting tidbit about C# 3.0/.NET 3.5. Since .NET 3.5 is just a bunch of new API's on top of the .NET 2.0 runtime, and C# is a translator as well as a compiler, the end result is still CLI that is compatible with .NET 2.0. So long as the appropriate assemblies are available, a .NET application written with C# 3.0/.NET 3.5 should run on a system with only .NET 2.0 installed. Sounds pretty portable to me. ;) Speaking of goto, I use it in two cases:
foreach (...)
{
foreach (...)
{
foreach (...)
{
if (exitCondition)
goto DoneWithLoops;
}
}
}DoneWithLoops:
// Finish upThats a lot cleaner than having a bunch of flags that have to be checked in every loop if a complete exit from all loops is needed. C# translates complete exits from nested loops into a goto anyway in a lot of cases, so the above code is whats going to happen anyway.
switch (...)
{
case 1:
{
// Do something that augments default
goto default;
}
case 2:
{
// Do something unique
break;
}
default:
{
// Do common stuff
break;
}
}aa) If I didn't notice Microsoft placed all related extension methods in an (almost) extension-method only namespace. I would be placing regular methods and etension methods in the same namespace.
Jon Rista wrote:
b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be?
I mean most LINQ extension methods implement a generic algorithm that works with any object as opposed to a function that performs an action on one object. On most blogs i've read, developers want to extend a type with a function they want so badly instead of considering deriving from that type and adding the function. cc) Since Microsoft developed this feature and must have researched it intensively, they should have at least warned us about it.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
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
-
Glad you like the Line Counter add-in. I've been poking at it lately, trying to improve it and make it work with VS2008 too. Hopefully another version will be released soon. As for C# 3.0/.NET 3.5, there are LOTS of useful things. WPF is certainly more resource heavy than basic windows forms, but its only one of the many new things available. You also have WCF, WF, LINQ (which isn't just for querying databases...it queries any enumerable type which is GREAT, you'll love it), anonymous types, partial methods, expression trees, class initializers, HashSet, and more. The LINQ features, which is where IEnumerable.Any comes from...its a part of LINQ, are probably the most useful addition to the language.
Yeah, I'll definately have to upgrade to VS2008 and start using the new stuff. That's cool that you have been poking at the line counter. I wouldn't mind seeing a toolbar added and the ability to calculate the contents of a folder. Calculating basedon namespaces, classes, interfaces etc. would be nice too but I imagine that would be a lot more work than folders.
-
Jon Rista wrote:
should be worded "can't"
Yes, but for me they're pretty much equivalent; if I can know it I do know it. Unfortuntely there are some who can know it but are too darn lazy to find out.
-
By "can't" I really meant can't. There IS no type for an anonymous type at design time...only at runtime. In that case, use of var is the only possability. You physically can't know the type.
Yes, we agree on that.
-
aa) If I didn't notice Microsoft placed all related extension methods in an (almost) extension-method only namespace. I would be placing regular methods and etension methods in the same namespace.
Jon Rista wrote:
b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be?
I mean most LINQ extension methods implement a generic algorithm that works with any object as opposed to a function that performs an action on one object. On most blogs i've read, developers want to extend a type with a function they want so badly instead of considering deriving from that type and adding the function. cc) Since Microsoft developed this feature and must have researched it intensively, they should have at least warned us about it.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
aaa) I prefer having them in their own namespace. That forces you to think about using them. To support your argument, it forces you to do something that will cause a "ported" app break at compile time if that extensions namespace isn't available. It also allows you to interchange extensions that do the same thing. If you decide you can do better than Microsoft and write the same IEnumerable extensions, that produce the same results, but perform faster...since they are in a different namespace, you can! Extension Method Best Practices[^] In regards to inheriting to extend functionality. Inheritance is good only to a certain degree, and is not always the appropriate answer. For one, there is the ongoing Composition vs. Inheritance debate. Two, deep inheritance chains are difficult to maintain and manage. Three, your not always looking create a whole new type. You just need more functionality on an existing type. The beauty of extension methods is, if you DO inherit from an extended type, your extensions are available on all derived types too. The only real caveat with extension methods is the possible future inclusion of a similar method name on the extended class. I havn't figured that one out yet, but I doubt I'll completely give up on extension methods because of one possible problem. Having extension methods replaced with a native method isn't necessarily a bad thing, either. For example, I have an extention method that determines if an ObjectContext for Entity Framework "contains" an entity. The result is either true or false...and the rules that determine that are static. I don't care if the implementation comes from my extension or a native implementation...I just need to know the result.
-
aaa) I prefer having them in their own namespace. That forces you to think about using them. To support your argument, it forces you to do something that will cause a "ported" app break at compile time if that extensions namespace isn't available. It also allows you to interchange extensions that do the same thing. If you decide you can do better than Microsoft and write the same IEnumerable extensions, that produce the same results, but perform faster...since they are in a different namespace, you can! Extension Method Best Practices[^] In regards to inheriting to extend functionality. Inheritance is good only to a certain degree, and is not always the appropriate answer. For one, there is the ongoing Composition vs. Inheritance debate. Two, deep inheritance chains are difficult to maintain and manage. Three, your not always looking create a whole new type. You just need more functionality on an existing type. The beauty of extension methods is, if you DO inherit from an extended type, your extensions are available on all derived types too. The only real caveat with extension methods is the possible future inclusion of a similar method name on the extended class. I havn't figured that one out yet, but I doubt I'll completely give up on extension methods because of one possible problem. Having extension methods replaced with a native method isn't necessarily a bad thing, either. For example, I have an extention method that determines if an ObjectContext for Entity Framework "contains" an entity. The result is either true or false...and the rules that determine that are static. I don't care if the implementation comes from my extension or a native implementation...I just need to know the result.
Jon Rista wrote:
Extension Method Best Practices[^]
Thanks for that link.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
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)?
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
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)?
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
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 :wtf: ; 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.
-
@4-10, were talking C# the language, version 4.0. Your points 4-10 are all framework features, not language features.
-
Yortw wrote:
8. Fix for the (very rare) bug caused by compiler optimisations on the String.IsNullOrEmpty function.
I thought they already fixed that in 3.0 or 3.5.
Last time I checked the bug report on connect.microsoft.com they had marked it as closed, "Won't Fix"... and I thought that was after 3.5 was released, but I could be wrong.
-
Yortw wrote:
8. Fix for the (very rare) bug caused by compiler optimisations on the String.IsNullOrEmpty function.
I thought they already fixed that in 3.0 or 3.5.