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.
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.
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?).
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.
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'.
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:
Thread.currentThread().getStacktrace()
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.
[+] [-] robgough|14 years ago|reply
[+] [-] recursive|14 years ago|reply
[+] [-] kyberias|14 years ago|reply
[+] [-] yonran|14 years ago|reply
Array.prototype.forEach.call(document.querySelectorAll("*"), function(x){if (getComputedStyle(x).position === "fixed") x.parentNode.removeChild(x);})
[+] [-] inafield|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] galactus|14 years ago|reply
[+] [-] joelangeway|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] Strilanc|14 years ago|reply
- 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'.
[+] [-] magic_haze|14 years ago|reply
[+] [-] jawher|14 years ago|reply
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.[+] [-] ppog|14 years ago|reply
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.
[+] [-] politician|14 years ago|reply
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.
[+] [-] edwinnathaniel|14 years ago|reply
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.
[+] [-] kodablah|14 years ago|reply
[+] [-] Tarks|14 years ago|reply
[+] [-] leon_|14 years ago|reply