C# 4.0
-
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
Lol I just realized this morning as I got up how dumb that was of me last night. You didn't forget anything--null would of course be the default, that's the whole point. :P "?? null" is redundant. :doh:
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Check out my blog! ) |)””’) piHole.org -”-”-
-
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 -”-”-
Actually, the posting I saw wasn't on CodeProject. It may still have been yours, but it wasn't here. Either way, it's a fantastic idea, and I really like it!
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
-
Actually, the posting I saw wasn't on CodeProject. It may still have been yours, but it wasn't here. Either way, it's a fantastic idea, and I really like it!
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
Wasn't likely mine, then--that's the only place I remember discussing it; but it could have been one of the other guys. On the other hand it could have been someone else entirely, which only goes to show it must be a good idea if people are coming up with it independently! If you do find the link, let me know; it would be interesting to read what other people suggested. It would definitely be nice to have in an upcoming version of C#.
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Check out my blog! ) |)””’) piHole.org -”-”-
-
Perhapse that should be worded "can't" know the type...as in the case of anonymous types. Its easy enough to debug and find out a type you don't know. Var has its uses, but like almost any language feature, it can be missused. I think rather than restricting its use, though, better educating our programmers and instilling good practices is the first thing we should try. ;)
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.
-
I think what your asking for can be fairly closely achieved already in C# 3.0..its just slightly more verbose: int[] tupleFunc() { double w, h, d; // ... return new[] { w, h, d }; } int[] tuple = tupleFunc();
Jon Rista wrote:
int[] tuple = tupleFunc();
But what i really want is to avoid having to unpack the array on the callee side of things.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
Static verification would be awesome. Contracts[^] would be nice too if they could get some of those features in without making too much of a mess. For instance, Spec# will throw a compile-time error (and squiggly underline in Visual Studio) with this code:
public float Divide(float x, float y)
{
return x / y;
}But this would be valid:
public float Divide(float x, float y)
requires y != 0
{
return x / y;
}As would this:
public float Divide(float x, float y)
{
if(y == 0)
throw new ArgumentException("y");
return x / y;
}I wholly agree. Contracts will help us write less buggy code, which should be a primary focus of new C# features.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
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.
Jon Rista wrote:
anti-progressive types
No, I'm a pedantic type! I do use one or two Extension Methods I've written. I know what Extension Methods do, and "adding functionality to classes" isn't it. They simply masquerade as class members. They are still just static methods and can be used as such. They have absolutely zero effect on the class involved. Any benefits (over classic static usage) they offer are purely superficial. I'm not saying they don't work. I'm not saying that the static methods that implement them aren't useful. I (and I'm not the only one) think that having a static method look like a class method is a bad idea; they seem to break orthogonality for one thing. When I see a snippet of code posted here or elsewhere (where Intellisense isn't involved) I can't tell one from the other. Other than that, I don't like the implementation; the change to the syntax was unnecessary, the developer should be allowed to put the attribute on the method directly.
-
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?
Bad example. How is that better than:
lookingFor = "%" + lookingFor ; lookingFor = lookingFor + "%" ; lookingFor = "%" + lookingFor + "%" ;The standard way is much clearer (at least in this case). -
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.
Jon Rista wrote:
Portability? Where are you going to "port" a C# or VB.NET app to...they only run on the .NET platform anyway.
Wrong. Look up Portable.NET[^] and Mono[^] There are also other compilation techniques out there. See IL2CPU on Cosmos[^] and Bartok used for the Singularity project.[^] I don't understand why programmers can't seem to separate C# from .NET. C# is a programming language with a syntax and rules. The C# life cycle of your project ends after you successfully compile your project. The framework you are using then executes the compiled binaries (and it doesn't have to be IL).
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
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.
Jon Rista wrote:
And that functionality is accessed through class INSTANCES...not static methods or utility types.
:omg: This is exactly why I said extension methods should come with a warning tag.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
But using them as Extension Methods is no more "powerful and useful" than using them as regular static methods. The "Extension Method-ness" isn't what makes the methods "powerful and useful".
-
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
A lot of the stuff from Spec#. At a minimum - preconditions, postconditions and invariants.
Kevin
-
Ennis Ray Lynch, Jr. wrote:
I have always said that developers need to focus on mastering what has been provided in 2.0 before even thinking about adding more candy.
Would it really be hard to "master" tuples as a return paramter? I love that feature as part of LUA and Python especially over out parametes. Spec# sounds interesting which adds support for explicit programming by contract.
Todd Smith
Todd Smith wrote:
Spec# sounds interesting which adds support for explicit programming by contract.
Yea! :)
Kevin
-
I'd love to see a const keyword on parameters to methods, and optional parameters. Both of which seem simple enough.
Christian Graus No longer a Microsoft MVP, but still happy to answer your questions.
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
-
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.
Not every developer writing C# code targets the .NET framework. I used IEnumerable.Where as an example which everyone would understand but it could be any set of extension methods from XYZ company.
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
A couple of things I would like is better control over memory. The automatic garbage collection is nice and I understand that it's usualy better just to let it be so it can collect when needed, but in some cases I know the memory can and must be freed like when processing a large import file. Also I would like to be able to "Destroy" an object in certain situations. By that I mean to have one method that can nullify all refrences to a particualar object. Another thing would be multipule inheritance, or at least some psuedo-composite type scenario. My company seels a website management tool which runs as a smart client, so I write a lot of UI code that is shared between web and windows. We have our own MVC style system so much of the "Controller" and "Model" code is common to both web and win, but we also have several methods we have to add to both web and windows controls to support that system. Our only option now is to use interfaces, but 90% of the implementation of those interfaces for each control could be shared, but is currently copied since both our web and windows controls can't derive off of a base class.
-
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
-
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.
James Lonero wrote:
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.
C++?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
-
C# is what I call a progressive language. It started out in a very simple, Java-like form in v1.0. But it has continually evolved into a richer, stronger, more expressive language that has only served to do one thing: Improve my productivity. Hard-core OO programming is a very limiting form of software engineering. Objects don't solve everything in the simplest way...on the contrary, rich object models with full inheritance and associative relationships can get in the way of providing a simple, effective, easily maintained solution. You have to use the right tool for the job, and objects are most assuredly NOT the right tool for every job. I for one am extremely grateful that Microsoft did not allow C# to stagnate like Sun allowed Java to. I use C# for what it is...a progressive, evolving language that has an EXTENSIVE amount of analysis and design behind it to ensure that features that are added provide benefit...not detriment. The end result, IMO, is an extremely powerful, expressive, flexible language that allows me to quickly solve problems without always having to resort to a complex OO mechanism. Sometimes, an enumerable collection of simple structures (tuples say), is all one needs to get the job done.
I certainly agree with that.
-
1. Retry keyword, from VB.NET (structured error handling) 2. Dyanmic intefaces, from VB.NET 3. AppActivate function, from VB.NET 4. Non-beta version of the parallel task library 5. Better WPF designers 6. Better user experience when working on single code file shared between .NET Framework and .NET Compact Framework projects 7. Improved keyboard/focus and dynamic control creation support in .NET Compact Framework (support for ActiveControl, ControlAdded/Removed events etc). 8. Fix for the (very rare) bug caused by compiler optimisations on the String.IsNullOrEmpty function. 9. A version of the various TryParse functions that returns the default value for expected type, instead of returning true/false with an out parameter. 10. TryParse on System.Enum. Probably a lot of other stuff too, but that's all I can think of off the top of my head :-D Tuples would also be cool :cool:
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.