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.
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.
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.
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:
Which will return an array containing all the info you'd like, with method names, line numbers and file names.
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.
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.
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.
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 ?
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.