What else is new in c# 5(mindscapehq.com)
mindscapehq.com
What else is new in c# 5
http://www.mindscapehq.com/blog/index.php/2012/03/18/what-else-is-new-in-c-5/
8 comments
As interested as I am in this, I decided to pass thanks to that share bar. Seriously awful.
I used the DOM inspector in my browser to delete. I barely noticed I was doing it. There are so many shitty layouts out there, I frequently tweak them to make them readable out of near instinct.
To my shame, this hadn't actually occurred to me. Duly done. Though I don't like that it came to that.
Not that I want to defend it but could you elaborate what exactly is so awful about it that it distracted you from reading the article. I didn't event notice it myself.
I see a vertical bar floating over 15 lines of the body text. I found it annoying to scroll the page to read around the thing.
Here's a screenshot with my browser open at the size I'm comfortably browsing the rest of the web with. When I went back to check I could in fact expand the page and push that off to the left, which is less annoying, but still not great.
http://d.pr/5IyI
http://d.pr/5IyI
I'm going to guess the same thing that made me hate it: it covers up the first few letters of about 10 lines in the middle of the window.
You can always remove it in the inspector. Perhaps this kind of nonsense merits a bookmarklet? I wonder whether this would fix many websites (I'm thinking AllRecipes?).
Array.prototype.forEach.call(document.querySelectorAll("*"), function(x){if (getComputedStyle(x).position === "fixed") x.parentNode.removeChild(x);})
Array.prototype.forEach.call(document.querySelectorAll("*"), function(x){if (getComputedStyle(x).position === "fixed") x.parentNode.removeChild(x);})
[deleted]
The author seems to find that lambdas capturing the same loop variable is counter intuitive, but, honestly, that's the behavior I would expect from it!
I confess to making the mistake many times of thinking that I was capturing a value when I was capturing a variable, but the author has me confused and concerned that the semantics of lambdas have been changed such that a lambda always captures the value and not the variable. Capturing variables is darn useful and more general than capturing values. It would be totally unlike MS to break all of my code as much as I wish they would in other cases, so I'm going to assume that they've done something more clever than that.
They haven't actually changes the lambda code at all, they have only changed the fact that previously the foreach variable was declared outside the loop, now it is declared inside the scope. The lambda still closes over the loop variable. If you code your own loop, feel free to declare the loop entities anywhere you like.
Exactly, I also find it a bit confusing. I assume they are capturing variables (it would be crazy otherwise!) but they treat loop variables differently (as if a new variable was created every time).
Yes, they are now creating a new variable in the `foreach` loop each time.
They aren't doing the same for regular `for` loops so their behavior with respect to lambdas won't change.
They aren't doing the same for regular `for` loops so their behavior with respect to lambdas won't change.
To add to this, Eric Lippert, a principal dev on the C# compiler team, mentions this in a StackOverflow response (http://stackoverflow.com/a/8899347/59111). He also blogged about the issue in general in a two part series, the first of which can be read here: Closing over the loop variable considered harmful (http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi...).
[deleted]
There's a couple notable omissions from C#5, with respect to what was implemented in VB.Net.
- No anonymous iterator functions. They are useful for correctly implementing iterators with eager validation and lazy iteration.
- No type inference when assigning an anonymous function to a local. Determining and typing out a function's type is incredibly slow compared to just 'var'.
- No anonymous iterator functions. They are useful for correctly implementing iterators with eager validation and lazy iteration.
- No type inference when assigning an anonymous function to a local. Determining and typing out a function's type is incredibly slow compared to just 'var'.
hmm.. I agree, (1) definitely is a common pattern, and it is often annoying to write a separate function just to do the lazy iteration.
Also really needed: code contracts within delegates. You can write them now, but the tool can't recognize them yet.
An ~60x240 box hovering over the text with only the word 'tweet' in it.
Is it just me or does anybody else think that polluting your code with debugging and logging informations is not such a good idea ?
I understand the value of these informations, but changing your method signatures to take them is going too far in my opinion, especially that there a a less obtrusive ways to achieve the same functionality: stack traces. I'm a Java developer, so I don't know the equivalent in C#, but in Java, you can get the stack trace (or call stack) of the current thread:
I understand the value of these informations, but changing your method signatures to take them is going too far in my opinion, especially that there a a less obtrusive ways to achieve the same functionality: stack traces. I'm a Java developer, so I don't know the equivalent in C#, but in Java, you can get the stack trace (or call stack) of the current thread:
Thread.currentThread().getStacktrace()
In .NET, you can just do "new StackTrace()" to capture the current stack of the calling thread. One minor risk with this may be if an optimiser has elided function calls (e.g. converted to a tail recursion). I'm not sure how realistic this is in the C#/.NET case, but having the information injected by the compiler eliminates the possibility.
Also, .NET stack traces only contain line numbers if the debugging symbols are deployed. With the attributes, the C# compiler can inject line numbers at compile time, obviating the need for symbols. Similarly, if a vendor uses an obfuscator, the stack trace will include obfuscated names but the compiler attributes will have injected the real names, making it much easier for developers to read the log files.
Finally, for scenarios like INotifyPropertyChanged, having the caller name injected at compile time is much more efficient at run-time than capturing an entire stack trace just to figure out which property setter is running. This may not a big consideration for logging, but for property setters it is definitely worth bearing in mind.
Also, .NET stack traces only contain line numbers if the debugging symbols are deployed. With the attributes, the C# compiler can inject line numbers at compile time, obviating the need for symbols. Similarly, if a vendor uses an obfuscator, the stack trace will include obfuscated names but the compiler attributes will have injected the real names, making it much easier for developers to read the log files.
Finally, for scenarios like INotifyPropertyChanged, having the caller name injected at compile time is much more efficient at run-time than capturing an entire stack trace just to figure out which property setter is running. This may not a big consideration for logging, but for property setters it is definitely worth bearing in mind.
I don't like the fact that the value of the parameters associated with the Caller* attributes can be overriden by callers because they're implemented as a special case of optional parameters.
On the other hand, if the mechanism by which the Caller* attributes work is extensible, it may be interesting to use the feature to provide alternate default values for arbitrary optional params (e.g. non-const default values).
On the other other hand, maybe changing the semantics of default value assignment is a symptomatic of language bloat.
On the other hand, if the mechanism by which the Caller* attributes work is extensible, it may be interesting to use the feature to provide alternate default values for arbitrary optional params (e.g. non-const default values).
On the other other hand, maybe changing the semantics of default value assignment is a symptomatic of language bloat.
Honestly, I'd like to see Maven/more tools in .NET more than language features for a very good reason: all the niceties of these new language features don't seem to contribute much to most .NET projects somehow.
Either people aren't using it, or the type of software that uses .NET don't need it, or the 98% programmers simply ignore it, or something else that I don't know/can't point them out.
So please Microsoft, give us Maven for .NET. NuGET and MSBuild aren't enough.
Either people aren't using it, or the type of software that uses .NET don't need it, or the 98% programmers simply ignore it, or something else that I don't know/can't point them out.
So please Microsoft, give us Maven for .NET. NuGET and MSBuild aren't enough.
Maven is a bad dependency/package manager because of the complicated nuance, XML, etc. Java 8 is even planning on using Project Jigsaw to get rid of it (IIRC). Something like Grape or Buildr would be a better model.
> Maven is a bad dependency/package manager because of the complicated nuance
What nuance ?
>XML
Fair point. I don't know what they were thinking when they decided not to use attributes, but come on, XML is not that bad.
> Java 8 is even planning on using Project Jigsaw to get rid of it (IIRC).
Wrong: Jigsaw is a modularity tool, maven is a build tool. Jigsaw is intended as a competitor to OSGi, not maven. Jigsaw won't compile your project, resolve your dependencies nor deploy your product.
> Something like Grape or Buildr would be a better model.
I beg to differ. I'm no big fan of maven either, but the idea behind it is pure genius, i.e. an implicit source layout and build lifecycle. Where in imperative tools like ant and co you'd need to repeat again and again the same snippets, compile all those files in the src dir into a bin dir, copy a bunch of resource files to the bin dir, package the whole thing in a jar or a war, place it in a target dir. Also, the dependencies management used to be a tedious task, with you hunting for the correct versions of jars, placing them in a lib directory, going as far as to version them. Most tools now tend to emulate maven's way of dependency management.
Nothing like this with maven: you just place your code and resources in standard locations, create a pom.xml file with just infos regarding your project (name, version and type), possibly the dependencies, and with standard commandes (mvn install for example), it will fetch the dependencies, build your porject, package it and install it.
Maven has its warts: verbose XML, unexpected behaviour in some cases, hard to customize (mostly when you try hard not to follow the standards), etc. But these are minor and fixable issues compared to the value it provides to countless developers who could fetch a project source and build it with one standard command.
What nuance ?
>XML
Fair point. I don't know what they were thinking when they decided not to use attributes, but come on, XML is not that bad.
> Java 8 is even planning on using Project Jigsaw to get rid of it (IIRC).
Wrong: Jigsaw is a modularity tool, maven is a build tool. Jigsaw is intended as a competitor to OSGi, not maven. Jigsaw won't compile your project, resolve your dependencies nor deploy your product.
> Something like Grape or Buildr would be a better model.
I beg to differ. I'm no big fan of maven either, but the idea behind it is pure genius, i.e. an implicit source layout and build lifecycle. Where in imperative tools like ant and co you'd need to repeat again and again the same snippets, compile all those files in the src dir into a bin dir, copy a bunch of resource files to the bin dir, package the whole thing in a jar or a war, place it in a target dir. Also, the dependencies management used to be a tedious task, with you hunting for the correct versions of jars, placing them in a lib directory, going as far as to version them. Most tools now tend to emulate maven's way of dependency management.
Nothing like this with maven: you just place your code and resources in standard locations, create a pom.xml file with just infos regarding your project (name, version and type), possibly the dependencies, and with standard commandes (mvn install for example), it will fetch the dependencies, build your porject, package it and install it.
Maven has its warts: verbose XML, unexpected behaviour in some cases, hard to customize (mostly when you try hard not to follow the standards), etc. But these are minor and fixable issues compared to the value it provides to countless developers who could fetch a project source and build it with one standard command.
I've never had any issue nor felt that Maven is overly complicated so far having done a few large projects with minimum Maven overhead (i.e.: haven't had the need to customize it).
I do agree with you that XML makes programmability aspect of it a little bit more complex than it should be (you still can write plugins if you have to, as opposed to use XML).
I do agree with you that XML makes programmability aspect of it a little bit more complex than it should be (you still can write plugins if you have to, as opposed to use XML).
Thanks for writing this, I hadn't yet seen the method caller stuff.
wow, that share thingy is ultra annoying.